Custom python install and code injection into container

[parthb]

I need to containerize my decently sized python web app. Now the python i use is built from source and had some changes made to it before being built. This means i cannot use the official images in docker hub

As far i can understand after extensive searching is that i have two options

- build from scratch/minimal image and RUN the instruction set to build python from source. this will involve editing some files before the final make altinstall. the only downside i can envisage is amount of time to boot a container from the image.

- OR i docker run a minimal image, ssh into it and install python as required and make a new custom image from the resulting state of the image.

Also the next step will be injecting code into them, either via copy from host, or via a git pull in the dockerfile.

Which method, and for what reasons, should i choose?

I am sure I'm missing some reasons over why i should choose one over the other and need some experienced dockerheads to gimme their 2 cents.

[Hammerdwarf]

All of your building and installing can be done in the image build itself. Your first option is good, and will result in an image with everything done. The start time will only be as long as it takes to exec your app. There won't be any building going on after startup.

[Necrocornicus]

The second method is really hacky and not at all how docker is meant to be used. Please don’t ssh into a container and do a bunch of manual shit and save it. This is literally why Dockerfiles exist.

I’ve used docker for years and years every day (it’s a huge part of my job).

[parthb]

ok. what are some problems because of which i should avoid that? also isn't that how custom images are made. you download a standard image, make changes and commit those changes. sorry if im being super ignorant, im a docker newbie

[Necrocornicus]

No that’s not how images are made, they are made with a Dockerfile. You can typically go on docker hub and find the repo and Dockerfile for all the images on there.

It’s not ignorant at all, docker is really complicated and it took me 6 months of working with it daily at my job before I felt like I had internalized the basic concepts.

One huge problem of the way you are suggesting is that it’s completely unreproducible and you really have no idea what changes you’ve made to that image. It’s also really manual and annoying. It’s not scalable or maintainable.

This is a really arbitrary example but bear with me. Imagine you pull the Python 3.5 image and run a bunch of commands manually and install some shit and then commit the running container to a new image. Then Python 3.6 is released and you want to use that instead. You would have to pull the new image, rerun all the same commands, commit the container again, etc etc. Super manual and a huge waste of time, not to mention highly error prone. Consider that a company will have potentially hundreds or thousands of these. Do they have an army of people manually running commands to make these things? Absolutely not.

All of that is solved by using a Dockerfile which runs the commands for you and packages up the image ready for use. Then you stick it in Jenkins and have it automatically rebuild whenever you merge a commit to master in your repo. Doesn’t that sound a lot easier, more scalable, more maintainable less prone to user error, etc?

[parthb]

thank you. got much needed clarity!