Do you ship your container dev to the stage, stage to prod? OR, clone the repo at production server and run docker command, like, docker-compose up --build
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (13)
No. I don't see any benefits for that. Docker container is already a virtual environment itself, not sure why I'd want to have another one inside it.
Do you ship your container dev to stage, stage to prod. OR, clone the repo at production server and run docker command, like, docker-compose up
CD does delivery to staging, once we're good with it, it's simply a click on a button to release it and ship to prod.
That's a good and valid point. Thank you
It's great when doing a multi-stage build on Alpine Linux - install your build dependencies, build your dependencies to a
.venvand then copy that from the build container to the actual runtime environment.Helps both you stage your Dockerfiles correctly for optimal build times, and with the end results cleaner and not having to worry about leaving C compilers etc. lying around.
Automated pipelines ftw. Have push to master trigger tests + builds + deployment automatically.
I don't like to have difference between my development setup and the production setup (containerized). I don't find it harmful to have a virtual env inside the container.
Do you ship your container dev to stage, stage to prod. OR, clone the repo at production server and run docker command, like,
docker-compose upAnd thanks for your thought.
We actually use K8s for dev, staging and production clusters. For development, we have containers that're orchestrated by
docker-compose.The flow is: Test things locally, once done, deploy to dev, then move to staging and finally deploy on production.
No virtualenv, no Docker.
Didn’t get your point. Can you please say a little bit more?
I do not use virtualenv, nor Docker.
:)
Ok then. Probably you could skip this discussion. Btw, thanks