You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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.
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.
The text was updated successfully, but these errors were encountered: