Docker, when to use it?

[woohoo]

I've watched a course on Docker, even use it at the current client. But I'm struggling to see what problems it solves. I'm not being critical it's probably that I've not experienced the issues that docker solves.

In the real world of software development/deployment when does it really become useful?

[b0redom]

I've watched a course on Docker, even use it at the current client. But I'm struggling to see what problems it solves. I'm not being critical it's probably that I've not experienced the issues that docker solves.

In the real world of software development/deployment when does it really become useful?

Docker lets you ship your dependencies along with your app in a container which theoretically can be run on any host OS - not sure how mature the Windows side is. For example if you have a JAVA app with a bunch of crypto dependencies, you just docker pull and then run.

It's lighter weight than a VM as it doesn't require a separate OS instance per container, and only the specific dependencies are shipped with the container image, not all of the OS binaries.

If you're doing docker containers right, you should also only be running a single process. That way when the process dies whatever you are using to orchestrate will notice and fire up another one to replace it (rancher/kubernetes etc).

It's nothing fabulously new, Solaris Zones, AIX WPARs and BSD jails have all been around and doing similar for ages.

[woohoo]

Docker lets you ship your dependencies along with your app in a container which theoretically can be run on any host OS - not sure how mature the Windows side is. For example if you have a JAVA app with a bunch of crypto dependencies, you just docker pull and then run.

It's lighter weight than a VM as it doesn't require a separate OS instance per container, and only the specific dependencies are shipped with the container image, not all of the OS binaries.

If you're doing docker containers right, you should also only be running a single process. That way when the process dies whatever you are using to orchestrate will notice and fire up another one to replace it (rancher/kubernetes etc).

It's nothing fabulously new, Solaris Zones, AIX WPARs and BSD jails have all been around and doing similar for ages.

Thanks, I can of understand most of that from the course. But I'm looking to see where I can use it.

So, when working in the cloud I'm mainly using PAAS, so I can't see it helping there. For other clients that have physical servers in-house. I usually deploy via teamcity/octopus etc.

Even where deploying code directly to a server it's never really been an issue ensuring the server has the correct dependencies.

So, I'm trying to think when/how I can use it.

[b0redom]

Thanks, I can of understand most of that from the course. But I'm looking to see where I can use it.

So, when working in the cloud I'm mainly using PAAS, so I can't see it helping there. For other clients that have physical servers in-house. I usually deploy via teamcity/octopus etc.

Even where deploying code directly to a server it's never really been an issue ensuring the server has the correct dependencies.

So, I'm trying to think when/how I can use it.

When you say PAAS, are you talking about using EC2 instances etc? The idea is, that you don't need to run Octopus deploy or whatever, you stipulate what the dependencies are, have the docker container pull your code (or bundle it up in the image) and then upload to your docker repo.

Then deploying to prod/dev/staging/QA etc follows exactly the same process. You just pull and run, no need to maintain an OS image etc. You can also deploy into ECS or whatever the equivalent is in Azure GCP etc.

For in house physical servers the selling point is that you get better ROI as you can run far more containers than VMs on a physical host.

[portseven]

Docker lets you ship your dependencies along with your app in a container which theoretically can be run on any host OS - not sure how mature the Windows side is. For example if you have a JAVA app with a bunch of crypto dependencies, you just docker pull and then run.

It's lighter weight than a VM as it doesn't require a separate OS instance per container, and only the specific dependencies are shipped with the container image, not all of the OS binaries.

Similar to the OP, I don`t quite get the use case for Docker, so from what you said the main benefit is has is that it`s lighter weight than a VM. So we are saving disk space, and cramming more workloads onto a physical server.

I think you can do everything you can with Docker, with a VM, its just you are saving money on less disk space, and CPU/RAM.

[b0redom]

Similar to the OP, I don`t quite get the use case for Docker, so from what you said the main benefit is has is that it`s lighter weight than a VM. So we are saving disk space, and cramming more workloads onto a physical server.

I think you can do everything you can with Docker, with a VM, its just you are saving money on less disk space, and CPU/RAM.

Yep. Plus you have a community provisioned repo of ready to roll docker containers running NGINX, MySQL etc (although YMMV based on the amount of trust you are willing to give it), a bit like AWS AMIs.

The reason devs love it is that it fixes the whole, 'well it works on my computer' thing. They can provide a docker container, and wherever you install/run it, the libraries, versions etc will be identical. If something breaks and needs fixing, they can reproduce exactly the same environment where it broke.

[woohoo]

Yep. Plus you have a community provisioned repo of ready to roll docker containers running NGINX, MySQL etc (although YMMV based on the amount of trust you are willing to give it), a bit like AWS AMIs.

The reason devs love it is that it fixes the whole, 'well it works on my computer' thing. They can provide a docker container, and wherever you install/run it, the libraries, versions etc will be identical. If something breaks and needs fixing, they can reproduce exactly the same environment where it broke.

Thanks...I see the whole thing it works on my PC, I can understand that. But in my entire career it's probably happened twice when the environment has differed and has caused a "works on my computer" thing.

Mostly, in my experience and I do mostly web apps nowadays, the "works on my computer" is down to the data or an issue integrating with a third party service. The last time it happened to me and it was down to the environment was about 4 years ago and not installing a legacy third party component.

I guess if I had several customers, running different versions of frameworks etc then it might be a bonus, but in 12 years of contracting it's never really been an issue.

[woohoo]

When you say PAAS, are you talking about using EC2 instances etc? The idea is, that you don't need to run Octopus deploy or whatever, you stipulate what the dependencies are, have the docker container pull your code (or bundle it up in the image) and then upload to your docker repo.

Then deploying to prod/dev/staging/QA etc follows exactly the same process. You just pull and run, no need to maintain an OS image etc. You can also deploy into ECS or whatever the equivalent is in Azure GCP etc.

For in house physical servers the selling point is that you get better ROI as you can run far more containers than VMs on a physical host.

So when I say PAAS, I'm talking of Azure and Application services. I don't maintain a VM, I just publish to a service. I can do that via github for example or directly from Visual Studio. I stipulate on the App service which version of the framework etc to use.

[portseven]

Yep. Plus you have a community provisioned repo of ready to roll docker containers running NGINX, MySQL etc (although YMMV based on the amount of trust you are willing to give it), a bit like AWS AMIs.

The reason devs love it is that it fixes the whole, 'well it works on my computer' thing. They can provide a docker container, and wherever you install/run it, the libraries, versions etc will be identical. If something breaks and needs fixing, they can reproduce exactly the same environment where it broke.

I still think you can achieve the same thing with a VM, devs create a VM image with everything they need, then send over the VMDK (or whatever format). A nice fully contained image. Yes VMDK is bigger, but storage and bandwidth are cheap.

BTW I fully accept I am being a luddite, and Dockers are the cool thing.

[Hobosapien]

The main advantage is containers are at a higher abstraction level to VMs. You don't have to worry about the OS itself and compatibility issues with introducing breaking changes. Multiple containers run within one OS and are isolated from it.

The next abstract level up is to do away with the container and run the code under FaaS (function as a service) where you only pay for function execution cost and not for having a VM or container sitting idle. i.e. Serverless ideology where whole IT teams are redundant as DevOps takes it to the extreme of only really needing the developer.