Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Containerization - Baked in environment variables on HTTP service for Admin and Survey #309

Open
chrimyn234 opened this issue Sep 24, 2024 · 1 comment
Assignees
Labels
question Further information is requested

Comments

@chrimyn234
Copy link
Collaborator

Context:

I am in the process of dockerizing the Intake24 applications and would like to streamline the deployment process by using Docker. My goal is to create a set of public Docker images (one for each app), which can then be used in a docker-compose file to simplify deployments across environments. The configuration will rely heavily on environment variables defined in the docker-compose.yml.

Current Setup:

Each app has its own Dockerfile and corresponding Docker image.
Environment variables are passed via a .env file (e.g. .env.api, .env.survey, etc) and referenced in docker-compose.
Traefik is configured as the reverse proxy to manage routing for these services.

Problem:

At the moment, I am encountering an issue where any changes to environment variables, particularly Axios' baseURL, require me to rebuild the Docker images and push them to the container registry. This adds complexity to the process, especially when the environment variables are the only things being changed (e.g., changing a URL for staging vs. production). It is not flexible.

Questions:

Is it possible to configure the Docker setup so that environment variables (such as Axios' baseURL) can be injected at runtime via docker-compose instead of being baked into the image during build time? This would save the need for rebuilding the images whenever environment variables change.

Would a solution like this be practical given Intake24's current architecture, or would you suggest an alternative approach?

Additional Context:

I'm open to suggestions for improving the Dockerization strategy, including any best practices for handling environment variables or simplifying the deployment pipeline. The goal is to avoid rebuilding and re-pushing images just for environment variable changes.

@chrimyn234 chrimyn234 added the question Further information is requested label Sep 24, 2024
@lukashroch
Copy link
Collaborator

@chrimyn234 it's known issue with SPA and their build process.

I think we would need to modify the bootstrapping a bit to allow runtime env vars to be substituted during the container runtime using envsubst command or something similar.

Not having to run envsubst on whole js bundle, we should extract all env vars used into the single file, which will hold the placeholders to be replaced. And modify the build process so that file is chunked out to be easily piped through envsubst.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants