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
We're a place where coders share, stay up-to-date and grow their careers.
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
Softhints -
Mark Gatere -
protium -
Ben Halpern -
Discussion (15)
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
.venv
and 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 up
And 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.
Says it better than I could have. +1
Great question! I will use pyenv (which comes with pieces to work with virtualenv) as it makes it easy to extend docker containers should I need to upgrade Python itself or any of its packages. But, as someone pointed out, docker itself is a virtual environment. So, if it makes sense for you to use a Python virtualenv then go for it. But, if it's not necessary for the particular container, there's no reason that you must use one.
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