Sysadmins btfo'd

>containerized applications all run on thin air and zero infrastructure needs to be configured to support it.

Nigger, you don't run your database in kubernetes, wtf are you event talking about

Cont. the entire idea of containerization (docker) and containerization is that programs can be easily moved between machines / scaled in/ scaled out. Database is supposed to be persistent, which is a contradiction if you want to use it in kubernetes that handles volatile containers.

Based

I would unironically prefer systemd-nspawn over these garbage utils.

>systemd
not

> implying Docker is better
Docker even was closed source for a while. It took off so hard because it was made for Macs as well.

Nigger is you. The idea of K8s/Docker is to provide deployment tools alongside with isolation tools, so Docker-compose and whatever k8s has. Anyway, Docker containers are non-persistent, but it's not rocket science to mount your /var/lib/mysql and binary logs from another storage. If it crashes, another instance would recover it.

>virtualization everything

Attached: NLDugGD.jpg (645x729, 34K)

Kek, retards like is the reason you still will need sysops.

Everyone besides in this thread is retarded. He's trying to make a point that admins are still needed, a good admin would be about to tell him how to do all this, and a great one would be about to write the configs for him to do so. You dumb niggers need to learn that just because orchestration is becoming popular doesn't mean our jobs are becoming easier, as the solutions we're solving now are 10,000x more complicated than before. Containerization is simply making the easiest step a bit less annoying.

They're called devops now

>Expecting developers to understand any CNI that isn't flannel
>Expecting developers to deploy a HA cluster when even the official documentation doesn't do a good job of it
Enjoy your single-master single-datacentre cluster with no network policies that'll halt and catch fire the moment kubelet or apiserver crashes.

Of course you can run databases in Kubernetes you gigantic mong. If you're using kubernetes properly, you want your databases inside it so you can leverage coredns for service discovery and a controller for recovery when your service dies. You handle persistence either with stateful sets or with an abstract storage layer presented as persistent volumes that are consumed by your database pods.

This. Based and Redpilled.

Attached: 49394410_2062992387113420_4647286048861192192_n.jpg (460x319, 28K)

Isn't it too much overhead for a database? K8s manages a cluster of nodes, separate machines that don't share storage. If you run your db in kubernetes, then it would have to mount the storage drive from some external storage (over network), and the performance of IO would be subpar.

Explain it to me, I've got an exam from this shit in a week.

You can taint a node and use it exclusively for DB.
Dunno about Docker, since that is still there, and it adds shitload of overhead for a database.

This.

People use Docker?
whats the point of that software besides putting another layer of complexity on your software?

Works on Mac the same it will work on a server (most of the time).

ye but what stops you to just mount the server partition onto your computer and compile it through a line command?

If you have a great latency you wont even notice it with SSHFS

Go read up on local pv's and node affinity - there's nothing stopping you from taking a non-containerized workload and making it a containerized workload. As in "run this pod on these hosts (who have these mountpoints backed by these disks)". Stateful applications are something kubernetes handles well these days. As for dropping IO throughput by pushing data over the network, keep in mind that contemporary networking equipment is fast. 10gbit switches are cheap. Provided you ensure the presence of persistent volumes on the local network of any database pod, and provided you follow best practice for databases in general (sharding, good indexes, good queries), you'll not see a noticeable impact until you're pushing NASDAQ numbers. With all that said, you can avoid any impact by sticking caching on the host running your database pod.
Docker, for all its flaws, makes things reproducible in complex environments. I know that if a developer asks me to deploy a container that I'm deploying exactly the same thing that they built and tested, and that they tested it in an environment that matches production. If all you manage is a singular self-contained service, then sure, it's better to avoid all this shite and just do it by hand. But when that one service depends on a database, a message broker, a reverse proxy and a handful of internal applications like SSO and logging, then not using containers means I'm suddenly managing two copies of each - one for production, one for development. And when one of the other developers, Pete, asks for his own copy of that environment because Steve broke dev while testing his shit CRUD app - I'm going to tell him to get fucked because I don't want to manage three copies of every application. We literally have a makefile that creates a complete copy of our entire platform. Developers run 'make environment' and they end up with a clean copy of what customers are using that day, on their own machines.

FOTM.

People tended to use a separate vm to run each application. Docker removes the overhead of the guest OS allowing you to better utilize your hypervisors. Kubernetes takes it even further by taking your hypervisors (your cluster) and dynamically allocating the containers in the most efficient way further optimizing your setup. Esentially, docker and kubernetes reduces the hardware (VM) resources you would have to invest in.

Then the next meme, Serverless, is another way of reduction of compute power you have to pay for. Imagine having an application that is idle all the time except when a request arrives, it performs some short code. Normally you would have to provision a VM, or maybe even few VMs, to run several copies of the application resulting in you paying for 24/7 usage of all the VMs. With serverless, you only pay for VM usage for the time, the code was executing. That is pretty good for simple, short tasks. Of course if you already have some other VM that could also fit your simple application, then you shouldn't bother with serverless. But it's still cool to have options.

You fucking retard there is nothing wrong with running it k8s.

I just finished setting up glusterfs which runs as a daemonset on my hosts and we're using heketi as a k8s storage provider, it's basically an API for glusterfs. Now whenever we require a PVC, we just define it in our deployment and BOOM. Instant persistent volume claim. If a host goes down, the pod containing the db will start up no problem on another host.

> Being this retarded
But that's cool, I'll shut down my shit, and let you do whatever. Good luck with that SAS-70 audit next week.

>10x easier job
>3x higher salary
Yeah, sure, never felt more BTFO'd imma life.

You have to use distributed storae system, like longhorn.

Sysadmins are failed programmers. Prove me wrong.

Based
Kill youreself stinky weeb NIGGER

Attached: 1544788861393.jpg (574x881, 54K)

>glusterfs
>database
pick one