Building a container to install from Docker or Portainer

[tempusthales]

Hey Jack as you requested I'm opening this thread for visibility and benefits of others pursuing to do the same. While I proficient with scripting and some development, I am a Docker & Docker Composer Noob and I mostly use Portainer to deploy my own Docker projects, so I'm aiming to build a deploy-able Docker Container of Crypter File Transfer and if possible deploy it via Portainer.

Based on our last convo over Ko-Fi:

The best way to run the project locally would be through the docker-compose "dev' profile. More info: https://github.com/Crypter-File-Transfer/Crypter/blob/main/Documentation/Development/Development%20Environment%20Setup.md#run-everything

Open an issue or a discussion topic on the repo if you need more support. Better for the community if we have this discussion over there.
To further clarify, those "web instructions are designed for my cloud use-case, where I have distinct "Web" and "DB" servers. The "dev" profile is designed for local development scenarios, as well as single-host environments.

I think this is a good place to start. Again thanks for your help!

[Jack-Edwards]

The outcome of this issue should be a good markdown file that gets added somewhere to the repo.

A couple more comments since that conversation in Ko-Fi occurred:

• Release v1.9.9 contains many changes that improve the support for persistent, self-hosted environments. Notable improvements are configurable CORS domains and the option to run database migrations on API startup. These settings are found in the API's appsettings.json file.
• The "dev" profile I mentioned was initially intended to support local development with self-hosted environments being an after-thought. The profile is now named "local" to better indicate the profile is meant for "I want to run everything on this particular host" scenarios.

[tempusthales]

Could you give an example of what would go in these variables?

${API_IMAGE_NAME} 
${WEB_IMAGE_NAME}
${CADDY_DOMAIN}
${CADDY_REDIRECT_TO_WWW}
${CADDY_OPTIONS}
${CADDY_TLS_VOLUME}
${CADDY_MAX_REQUEST_BODY}
${API_STORAGE_PATH}
${API_SETTINGS_FILE}
${POSTGRES_HOST}
${POSTGRES_USER_PASSWORD}
${POSTGRES_HANGFIRE_HOST}
${POSTGRES_HANGFIRE_USER_PASSWORD}
${WEB_BIND_PORT}
${WEB_SECURE_BIND_PORT}

[Jack-Edwards]

If you are building the images locally and running every service on the same host, you would leave most of those options alone. Their current values in the repo are configured for single-host, self-hosted scenarios.

Specific options that may need to be set:

• CADDY_DOMAIN
• • If you have a custom domain, then set that here. For example, www.crypter.dev.
• CADDY_REDIRECT_TO_WWW
• • I set this to crypter.dev to redirect all traffic to the www subdomain.
• WEB_BIND_PORT
• • Listen for HTTP traffic on this port.
• WEB_SECURE_BIND_PORT
• • Listen for HTTPS traffic on this port.
• POSTGRES_USER_PASSWORD
• • Provide a cryptographically strong password here. A default password is provided, but it's clearly not secure.
• POSTGRES_HANGFIRE_USER_PASSWORD
• • Provide a cryptographically strong password here. Same logic as above.
• API_SETTINGS_FILE
• • Any path on the filesystem. Drop your API's appsettings.json file here.

[tempusthales]

If you build the images locally and run every service on the same host, you would leave most of those options alone. Their current values in the repo are configured for single-host, self-hosted scenarios.

I tried leaving those variables alone, but when I compiled them in Portainer, I would get a ton of errors. I was wondering if the content I added to the variables was wrong, so I wanted to double-verify with you first.

[Jack-Edwards]

Strange. You could always copy the default values from the compose files, then override as necessary. I've never worked with Portainer before. Sent from Proton Mail mobile

…

-------- Original Message --------

On Dec 8, 2023, 5:32 PM, Gilbert Palau wrote: > If you build the images locally and run every service on the same host, you would leave most of those options alone. Their current values in the repo are configured for single-host, self-hosted scenarios. I tried leaving those variables alone, but when I compiled them in Portainer, I would get a ton of errors. I was wondering if the content I added to the variables was wrong, so I wanted to double-verify with you first. — Reply to this email directly, [view it on GitHub](#658 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AJBOINGOGE222P6HA5Y76A3YIOPRXAVCNFSM6AAAAABAEOPRMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBXHE3TCMBWHA). You are receiving this because you commented.Message ID: ***@***.***>

[tempusthales]

I've never worked with Portainer before.

Portainer is Docker with a web ui. In the case of loading a docker compose file I get the following:

That is why I asked (again I'm a docker noob) about the variables... I guess I'll just do that since you explained how to fill in the blanks.

What should I use in this variable? You didn't include it on the list above:

ghcr.io/crypter-file-transfer/${API_IMAGE_NAME:-crypter_api}:latest

[Jack-Edwards]

Just now seeing this. Apologies.

My first thought it Portainer is not observing the .env file in the root of the repo. Portainer suggest renaming the .env file to stack.env if I'm reading this correctly. Worth a shot. https://www.portainer.io/blog/using-env-files-in-stacks-with-portainer

The :- syntax in that variable name means if a value for API_IMAGE_NAME is not provided, then the value will default to crypter_api. Leaving it as crypter_api is fine, though make sure you are always building the image locally before you try running the container. Otherwise you risk pulling the image from GHCR. As a preventative measure, you may just want to delete the image definitions from the compose file.