CODEWITHSUNDEEP
dockergithubdeploymentgit-clone
pythonlover12345
pythonlover12345

Reputation: 43

Question for code deployment(pulling code when runtime)

I have a question about code deployment.

My team used to make a Docker image for sharing several applications. For example, a Docker image only have dependencies for several applications, and when I run the container from that image, I do 'git clone' my code what I want to deploy from Github.

I have thought it's not a proper way to use Docker. So I asked about it, and heard that "Yes, It's not a good way to use Docker. And before that, google about 'pulling code when runtime'". But when I googled about it, there were not enough results.

Since my team used to deploy many applications by 'git clone' even when not using Docker, I really want to know why pulling code when runtime is bad.

"Why pulling code when runtime is bad?"

Upvotes: 0

Views: 99

Answers (1)

David Maze
David Maze

Reputation: 158995

Imagine that, every time you wanted to ask or answer a Stack Overflow question, you needed to download the source for Chrome and recompile it from source. This obviously takes a long time; and sometimes the network or the remote server has a hiccup and downloading the source fails; and it's not actually Chrome, it's your private fork of it, so you need to either re-enter your GitHub password every time you run it or save that password somewhere. So you don't do that, you compile the application once and then run the compiled binary.

Docker is like that: an image is a self-contained object that contains an application, its language runtime, and all of its dependencies. You can just docker run it and it will start, without needing to pull code or contact a remote server.

The downside of this is that you need to rebuild the image whenever you change code. This is pretty routine anyways for a variety of common language environments (C, C++, Java, Go, Rust, Javascript via Typescript or Webpack) and it's a step your continuous-integration (automated build) system can do pretty straightforwardly. Typical practice is to build a new image on every commit to your source code system, and to deploy only the built self-contained image.

It's also worth noting that Docker is a relatively new technology and there's no requirement to use it. If you have a workflow that's based on using a tool like Ansible or Chef to deploy a language runtime to production systems, uses an interpreted language that doesn't need a build step (Python, Ruby, plain Javascript), and directly pulls source code from a source control system, you can absolutely keep using it if it works.

Upvotes: 1

Related Questions