3 ms·

Docker has a bunch of pros and cons, but to me the most important thing is that it standardizes a 'good enough' way to deploy servers. That means I can have one

Docker has a bunch of pros and cons, but to me the most important thing is that it standardizes a 'good enough' way to deploy servers. That means I can have one dev write some docker files used to deploy a server, then later switch to a different dev and the other dev should be able to easily figure it out. Contrast that to before when people had custom scripts and VMs and you would always need to spend time digging in to figure out what is actually happening and whats breaking. Its not perfect, but its good enough and there is a lot of support for it, so its easy to plug into my team.

spencerchubb 4y ago
When you put it that way, it does sound like quite a nice benefit to have a standard way to deploy. I will persist with docker and develop on Linux more as other people have said.
stingraycharles 4y ago
It's also very good for CI, to put all the dependencies and the entire build process in code that way. In the pre-docker days, you had a lot of configuration management inside the CI agents. Nowadays, often all that they need to do is be able to run Docker (+ manage secrets and a few other things) and you're good to go. I have never liked Docker for local development, apart from running external dependencies (e.g. have postgresql and redis launch through docker-compose in a standardized way). Local development of company code should not use Docker, too much hell with caching and (as OP notes) discrepancies between developer environments. (On that note, I have found that developers typically use Docker very different from people that work on CI / deployments -- more often than not, I've seen devs just have continuously running docker containers, executing all kinds of commands on them, save/loading them, etc, without using any Dockerfile at all. That just makes me irk, I don't understand that type of flow)
- lovehashbrowns 4y ago
  Local development is way easier with Docker for certain things. It’s great to have known and consistent package versions, a build process that’s documented by the nature of dockerfiles, and having a fairly standardized deployment method. There’s been plenty of times in my work history where I had to take what was a legacy application nobody knew anything about and went through the process of deploying it using a container. The biggest problem was figuring out how to get the thing to actually run; “I don’t even know anything about Scala. What the heck even is sbt, no clue.” But just starting out with a blank image where I can install random things that don’t affect my machine is great, and once I finish the process now everybody knows how it’s deployed; it’s in the Dockerfile. If I want to explain it in a readme, I copy and paste what I have in the dockerfile and expand on it, going step by step. When that image is deployed in an EC2 instance running our standardized AMIs, I know it’ll work; I’ve tested it. Converting that deployment image to run unit tests just means changing a few commands in the dockerfile, and now Spinnaker can run tests before the image is deployed anywhere. Easy pickle. At my current job, we do not currently have a process like that. We have Jenkins workers where we occasionally have to install different packages that the devs need in order for their build process to work as expected, and we have to have Jenkins workers specifically for that team. If they ran their builds in a container instead, we wouldn’t have that issue. At my previous role, our Jenkins nodes were regular EC2 instances running our standard AMIs and the dev teams built their code inside a container. When I had to build Python packages, it didn’t matter what Python packages were on the system, or that the EC2 instance didn’t have Python-dev and GCC installed. Build happens in a container. I know the build will succeed because I tested it locally on my machine.
agumonkey 4y ago
Yeah, it's socially fit, so a big chunk of the crowd naturally converged on it because it reduced efforts enough.

spencerchubb 4y ago

When you put it that way, it does sound like quite a nice benefit to have a standard way to deploy. I will persist with docker and develop on Linux more as other people have said.

stingraycharles 4y ago

It's also very good for CI, to put all the dependencies and the entire build process in code that way. In the pre-docker days, you had a lot of configuration management inside the CI agents. Nowadays, often all that they need to do is be able to run Docker (+ manage secrets and a few other things) and you're good to go. I have never liked Docker for local development, apart from running external dependencies (e.g. have postgresql and redis launch through docker-compose in a standardized way). Local development of company code should not use Docker, too much hell with caching and (as OP notes) discrepancies between developer environments. (On that note, I have found that developers typically use Docker very different from people that work on CI / deployments -- more often than not, I've seen devs just have continuously running docker containers, executing all kinds of commands on them, save/loading them, etc, without using any Dockerfile at all. That just makes me irk, I don't understand that type of flow)

lovehashbrowns 4y ago
Local development is way easier with Docker for certain things. It’s great to have known and consistent package versions, a build process that’s documented by the nature of dockerfiles, and having a fairly standardized deployment method. There’s been plenty of times in my work history where I had to take what was a legacy application nobody knew anything about and went through the process of deploying it using a container. The biggest problem was figuring out how to get the thing to actually run; “I don’t even know anything about Scala. What the heck even is sbt, no clue.” But just starting out with a blank image where I can install random things that don’t affect my machine is great, and once I finish the process now everybody knows how it’s deployed; it’s in the Dockerfile. If I want to explain it in a readme, I copy and paste what I have in the dockerfile and expand on it, going step by step. When that image is deployed in an EC2 instance running our standardized AMIs, I know it’ll work; I’ve tested it. Converting that deployment image to run unit tests just means changing a few commands in the dockerfile, and now Spinnaker can run tests before the image is deployed anywhere. Easy pickle. At my current job, we do not currently have a process like that. We have Jenkins workers where we occasionally have to install different packages that the devs need in order for their build process to work as expected, and we have to have Jenkins workers specifically for that team. If they ran their builds in a container instead, we wouldn’t have that issue. At my previous role, our Jenkins nodes were regular EC2 instances running our standard AMIs and the dev teams built their code inside a container. When I had to build Python packages, it didn’t matter what Python packages were on the system, or that the EC2 instance didn’t have Python-dev and GCC installed. Build happens in a container. I know the build will succeed because I tested it locally on my machine.

agumonkey 4y ago

Yeah, it's socially fit, so a big chunk of the crowd naturally converged on it because it reduced efforts enough.