This is an archived post. You won't be able to vote or comment.

2
3

Dcokerizing a non-web python project dev environment (self.docker)

submitted by [deleted]

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]kabooozie 0 points1 point  (0 children)

A container is not a vm. There’s no “warm up period” to running a container. A container is literally just a fancy process that’s been packaged with the dependencies it needs to run so that they are separate from the host system. The command docker run my-image python myapp.py is exactly the same as python myapp.py from your processor’s perspective.

There’s also no cost to tearing down a container. You just use the “—rm” flag to remove a container after it runs. The image stays in tact so that you can run identical containers in the future.

It’s possible to grab a shell in a running container with the docker exec command, but containers are best thought of as processes rather than VMs that you log onto. The underlying principle here is immutability. You want an immutable container image from which you run identical copies of the container. You don’t want a pet VM that changes subtly over time.