4 ms·

This is an oversimplification and Docker is easy from a basic usage standpoint like most tutorials are. The hard part is when you start configuring and configur

This is an oversimplification and Docker is easy from a basic usage standpoint like most tutorials are. The hard part is when you start configuring and configuring to your own requirements. What baseimage should you use? How about logging? How about PID 1 problem? Do I need an init system? How about SSH? Remote Docker containers cannot be accessed remotely for ex AWS Fargate. How about restarting servers? I need to do it gracefully. How about migrations? One-off scripts? Personally, I love using Docker but it’s those small things that make it hard and all the complexity around setting them up.

TechWizOfFortun 6y ago
Just replying to your comment, not trying to start an argument but just throwing out some thoughts. Please let me know if I'm off track in my response. What baseimage should you use? - You can always create your own docker base images. I do agree that it gets confusing when you pull a docker image and it's not using the linux flavor that you were expecting. Building a docker image is quite simple though. How about logging? - If using Kubernetes, you can use a 'side car' pattern with a log exporter. How about PID 1 problem? - I'm a little confused what you mean, but I think you are referring to killing PID 1, which would kill the docker container. If you're using Kubernetes in production, then Kubernetes would solve the problem of routing to docker containers that are up or down. How about SSH? - You would have to SSH into the host with the docker container present, and drop into the docker container thereafter. Remote Docker containers cannot be accessed remotely for ex AWS Fargate. - I haven't used AWS Fargate before, no comment. How about restarting servers? - Handled by Kubernetes, totally ok to restart the servers and requests won't be routed to dead (5xx) containers. How about migrations? - Deployments are simple using Kubernetes (built in rolling deployment, but also easy to do blue/green deployments). If you want to migrate a database, then it'd be the same process as non-container deployments.
andrewzah 6y ago
"Docker is easy from a basic usage standpoint like most tutorials are" This applies to basically any software or tooling once you get away from the initial tutorials. They wouldn't be tutorials if they covered all sorts of specific use cases particular to your own situation. "The hard part is when you start configuring and configuring to your own requirements. What baseimage should you use? How about logging?" Either the same distro you would use on a bespoke server, or you can optimize with alpine or scratch. Logging can be as simple or complicated as you want it to be, regardless if you use docker or not. "How about PID 1 problem?" We use s6-overlay [0] to manage this. When a service dies, a script gets executed, giving us control over how to handle it. "How about SSH?" For us, we use ansible to provision/set up kubernetes with ssh keys, then access pods and containers through kubernetes' cli. It isn't particularly -nice-, but it does work. "How about restarting servers? How about migrations? One-off scripts?" This is managed through kubernetes. You can restart servers and make deployments. [0]: https://github.com/just-containers/s6-overlay#features https://github.com/just-containers/s6-overlay#features

TechWizOfFortun 6y ago

Just replying to your comment, not trying to start an argument but just throwing out some thoughts. Please let me know if I'm off track in my response. What baseimage should you use? - You can always create your own docker base images. I do agree that it gets confusing when you pull a docker image and it's not using the linux flavor that you were expecting. Building a docker image is quite simple though. How about logging? - If using Kubernetes, you can use a 'side car' pattern with a log exporter. How about PID 1 problem? - I'm a little confused what you mean, but I think you are referring to killing PID 1, which would kill the docker container. If you're using Kubernetes in production, then Kubernetes would solve the problem of routing to docker containers that are up or down. How about SSH? - You would have to SSH into the host with the docker container present, and drop into the docker container thereafter. Remote Docker containers cannot be accessed remotely for ex AWS Fargate. - I haven't used AWS Fargate before, no comment. How about restarting servers? - Handled by Kubernetes, totally ok to restart the servers and requests won't be routed to dead (5xx) containers. How about migrations? - Deployments are simple using Kubernetes (built in rolling deployment, but also easy to do blue/green deployments). If you want to migrate a database, then it'd be the same process as non-container deployments.

andrewzah 6y ago

"Docker is easy from a basic usage standpoint like most tutorials are" This applies to basically any software or tooling once you get away from the initial tutorials. They wouldn't be tutorials if they covered all sorts of specific use cases particular to your own situation. "The hard part is when you start configuring and configuring to your own requirements. What baseimage should you use? How about logging?" Either the same distro you would use on a bespoke server, or you can optimize with alpine or scratch. Logging can be as simple or complicated as you want it to be, regardless if you use docker or not. "How about PID 1 problem?" We use s6-overlay [0] to manage this. When a service dies, a script gets executed, giving us control over how to handle it. "How about SSH?" For us, we use ansible to provision/set up kubernetes with ssh keys, then access pods and containers through kubernetes' cli. It isn't particularly -nice-, but it does work. "How about restarting servers? How about migrations? One-off scripts?" This is managed through kubernetes. You can restart servers and make deployments. [0]: https://github.com/just-containers/s6-overlay#features https://github.com/just-containers/s6-overlay#features