Am I too retarded to understand why people containerize everything...

>It's not meant for setting up stuff like a single LAMP stack.
Any yet I constantly see people doing it, that's the point I've been trying to make.

I'm creating a Spring Boot application with access to a MariaDB. On my live server it will be Nginx+Spring Boot+MariaDB while the database will be deployed on a seperate server. I can't see how Docker would make my life easier unless I'm not seeing something.

95% of Linux admins these days are using clusters.

if suddenly you wanted to spin up multiple instances of your spring application it would become useful

>I can't see how Docker would make my life easier unless I'm not seeing something.
Didn't I just mention it wouldn't make your life easier? Are you retarded? It's literally made for environments with 100's of servers.

I just wanted to make sure because some in this thread seem to claim otherwise.

Reproducible tests, reproducible deployment environments. Deploying on your cluster is easier since you have standardized containers and this makes HA and canary deployments (easy rollbacks!) easier. Also, the other incompetent devs on your team can't use "but it works on my machine" as an excuse.

If you don't see the value of those or need those benefits then you will not be convinced.

Spring Boot sucks major dick. DI is a meme from the 2000s.

>Any yet I constantly see people doing it, that's the point I've been trying to make.
Just because you see people jumping of a bridge doesn't mean it's healthy.

It most likely won't because you most likely don't have a need for micro services because your environment, application, customers, infrastructure, finances aren't as big as they would be in the enterprise.

If you would be in a big corp, you'd skip Nginx, terminate SSL on loadbalancers. One entity less, 2 more to go. The rest can be containerized. You write develop your images via stuff like terraform, keep it in git, have build jobs on jenkins that follow specific procedures like "if new version on git, build new test. if test built successful, deploy on dev". For prod you have similar concepts just that you rather focus on "if resources exhausted, grab stable build version and start new container instance.
That way you save resources, administrative complexity and reduce attack vectors from a security perspective. The entire working paradigm is a different one. Your initial configuration doesn't happen with ansible or puppet anymore, your configuration is the instruction set of what your container image needs to run. Your code repository is your software repository. You don't need a package manager anymore, you work with your repository server. You don't ssh into a box, you know how your application is designed, you know what it needs, where it needs to talk to, how often and at what performance costs in terms of network speed and io, based on these factors you scale your infrastructure.

If you are not a retarded motherfucker you setup docker hosts on bare metal and have separate network segments so you can run as many micro services that can scale well and don't disturb another

Damn, you know your shit. You almost scare me.

Docker is great because of how easy and fast it is to have new containers up doing 1 single function.

it really is because of how easy it is. and how generally reliable it is

> It's not meant for setting up stuff like a single LAMP stack.
Companies still do it. I believe Synology installs Docker containers for every application.

>Am I too retarded to understand why people containerize everything?

if you have to ask then yes

Suppose you are building an app with an sql database, redis cache, some backend server, and some frontend static files that need to be built with webpack.

Without docker you have to:
Download and set up your db, redis, language you chose for server + any env variables, on your dev environment and your server and that is repeated for every team member.

Instead you or someone of on your team can write docker files that only requires you setup docker run docker-compose --up and then everything is working.

The dockerfiles many times end up resembling the setup steps you will need to do manually in you dev environment/server.

And thats just a simple use case, but once you have that you can already start looking into things like automated testing or continuous integration and deployment.

Not OP but I was always told a few years ago that databases should not be put in a container, as it adds another failure point that can put your DB down. Does this still hold weight in 2018?

>docker-compose
This runs all the containers on your machine, right? Suppose I want to "distribute" my app containers to multiple different physical machines, is docker-swarm a good tool to use then? Or is everyone using kubernetes these days?

>as it adds another failure point that can put your DB down. Does this still hold weight in 2018?
I always thought it was for performance reasons, overhead, etc. I think it's still the commonly recommended thing to not put DBs in containers

Is it okay just to upload the container you use in your test enviroment? Because otherwise I would have to import SQL dumps etc..

Im no expert and just use for a single application like the one described above, but I also remember hearing about not dockerizing databases. I havent looked further into it because I havent reached production, but for development it at least allows me to nuke it and put it back up way easier, or for hosting it temporarily,

> This runs all the containers on your machine, right?

I believe so, at least thats how I use it, wanted o give docker swarm a try, as I heard it is simple than kubernetes, but when I saw that docker discontinued one of their swarm offerings makes me doubt of its future support. But yeah, I believe most people are using kubernetes these days.

vsupalov.com/database-in-docker/

I am not sure if I get what you mean, with the db, when you so when I build the container, it creates a virtual volume the machine running it for persistent data, and loads a sql dump file I provide,

I can either share my source code with the sql dump file and an env file for things like db password, or share the resulting image with the sql dump already in it.