So, welcome to MySQL Operations with Docker. For the ones who don't know me, my name is Giuseppe Maggia. I have a blog, The Data Charmer. I'm known with this name on Google as well.

I'm a community MySQL operator since a long time. I've been working for MySQL, the company itself, and for several companies involved in the MySQL ecosystem.

Today, we are going to talk about containers, and I just want to make sure that you understand what I'm talking today is not a representative. My company is my own opinion. So if I make any mistakes on my own, don't blame my company for that. If there is something good, it's my fault.

So let's talk about the container. First, let's see what we have, what are our possibilities instead of containers. You know, if you use bare metal servers, this is the optimal solution. It's a lot of power, but you need time to deploy them.

You need to take them with tracks. You need to install them and install operating system, a lot of things. So standalone servers are useful, but not the optimal solution.

You can use standalone servers to run several things at once. It's good because they are very fast. It's bad because things can clash. So you cannot separate one application from the other. You may have conflicts. You may have things that are supposed to play well together,

but they don't. So even though this could be useful, sometimes, most of the times, it leads to problems. Then, the solution that you usually have is virtual machines.

Virtual machines means that you have full isolation. You just take something that looks and feels like an operating system, but is not. It's pure software. And you pay for this. You pay for this with performance, usually, and also with a bit of time. So virtual machines don't deploy instantly.

Depending on how you are organized, you can take minutes to house to have virtual machines available. So this is something that allows you to have a lot of servers doing a lot of different things in isolation,

but not as fast as you would like to when you use real servers. And then, recently, you have the idea of containers. And this container is something that looks a bit like a virtual machine, but is not. It's a thin layer of software that is on top

of a Linux machine. And I say Linux machine because, so far, the container systems are mostly on Linux. And then the container contains only the libraries that are needed for your application, on top of this thin layer that is your application itself.

So it looks and feels like a virtual machine, but the difference is that this deploys in seconds, actually deploys in a fraction second, compared to virtual machines. One other thing that you can do with containers,

you can share the libraries between containers. So the net result of this is that you can run the same thing that you run in a virtual server, but much faster, because your application is using directly,

or almost directly, the same kernel that a server deployed on bare metal would. So what is a container? It's a virtualization system, but it's not a virtual machine. You don't need to install an operating system

to use a container. The container has already something that is an operating system. Or at least, it's a layer of libraries that make it feel like an operating system. And it works very close to the operating system. So compared to a virtual machine,

this is way, way faster. It's less secure than a virtual machine. So you have less isolation that you would have with a virtual machine. Mostly, the thing that you need to know is that if you don't try it, you don't believe it.

So this is the same thing that happened to me when I first started using split system after having used C language to write system maintenance code. You know, it's a madness. But the first time that I started using Perl and Python,

I was like, why did this to myself? So the important thing to know is that until you try it and you see, wow, I can have a new Ubuntu server in 0.5 seconds, or I can have a new Apache server in 0.2 seconds,

this is wonderful. One thing that you need to understand, though, is this works only on Linux. So if you are trying to use Docker on Mac, like this one, what you are doing, you are running Docker not on the Mac itself,

but on a virtual machine that is running Linux. This is because Docker uses Linux. So I suggest that you take a pure Linux machine and you try that on your server. But, you know, even on this, that we are using a virtual machine on top of the OS X operating system,

it's still faster than a regular virtual machine. So you need to install Docker. If you are on Linux, you use acting, GET, or YARN, or you can use the getdocker.com script to install on your Linux. Whatever you do is fine.

The latest one will deploy the most common current version of Docker. On Mac or Windows, you need to use the Docker machine that I mentioned before.

So we are talking about Docker using MySQL, or MySQL using Docker. So the first thing that you need to do, you have to deploy the MySQL image. This is not like downloading the full MySQL server, because this is a very slim version of MySQL.

So it has the bare minimum that you need to run a MySQL service. This will be very fast. I mean, in my computer, I run this operation in about one minute, just because I use a faster network.

But it should not be more than 15 minutes if you have a slow internet connection. Once you have done this, the image is in your computer, and it doesn't need to happen anymore. So from now on, every time that you deploy a MySQL container,

it will be a matter of half a second or less. If you want to know what is available, you go to hubdocker.com and look for MySQL. You will find two things. You will find one thing that is called the official MySQL image.

This is official for Docker, meaning that it's the Docker team that is maintaining a MySQL image. And then you will have the thing that I used today, MySQL slash MySQL server, which is official from the MySQL team. So it's the MySQL team that is maintaining the real image at Docker.

Whatever you use, it more or less works in the same way in the example that I'm going to show. So since we are talking about beginners here, people who have never used Docker, there are seven things that you need to be aware of.

The first thing I mentioned already, container is a full system. It's not a virtual machine, but it feels like one. So there is something that is a real Linux operating system inside. Containers are always Linux.

So whatever you use as a host operating system, what is inside the container will play well with the host container. You may have a host operating system that is Ubuntu and use a container that has CentOS

all the other way around. They will work together well. The current MySQL image is based on Debian. Another thing to be aware of is that the software inside the container is minimal.

Don't expect to have everything that you find in a regular Ubuntu deployment. You will have only the minimum that is necessary to run MySQL. So if you need to have something else, you need to work on it. More about this later.

Another thing that is proper of the MySQL container is that the installation requires a password. You either pass a password during the installation on the common line, or you tell the container, generate a random password for me. This is only useful if you want to use

a single container only once and then you want to change the password manually. If you are running lots of containers at once, don't do that. Use it without the password on the common line with a script, otherwise you will be in trouble.

Containers are isolated. I mentioned before that they are less isolated than a virtual machine, but they are nonetheless isolated. It means that you cannot access the container from the host operating system unless you take steps to do that. So container will only communicate with other containers.

Data storage can be tricky. So by default, the container will have the data inside the container itself. And since containers are designed to be volatile, so to be used and eventually disappear, actually you should be prepared for this case, keeping the data inside the container

might not be the right thing to do. So there is a technique to do something different and I will show that at the end. Configuration does not require you to modify the container. It's not like a virtual machine where you deploy the virtual machine, then you run Puppet or Jeff and you apply a formula to do what you need to do.

The container should be ready to use the moment you deploy it. And to do that, you deploy it with scripts or with orchestrators that will deploy the containers with the files that you need to have at startup.

So the container will show up in the wild, ready to be used. So let's see a few examples. First, simple MySQL deployment. This is how it looks like. You do a Docker run, name, and then you give a name that you will later use from Docker.

This is what I mentioned before. MySQL root equals password. MySQL root password equals secret. You need to pass one password this way. Then minus D means this is a daemon. I want it to continue work after this command.

And this is the name of the image that will be used. What you see here that will change every time that you run that command, this is the identifier of the container. But you can identify the container with the name that you have passed here.

So when you run this, you will have the MySQL server that is deployed with the default values. Let's say that you want something different. Now there is a nice trick in the MySQL image

that if you pass more information after the run command, like in this case, you can have this pieces of information go directly to the server. So if I do like this, I will have not the default, I will have a server that has not been enabled

and a server ID. Yes. Can you see how it's all in one of the slides? If you will give this, your root password is no more secret. Will there be another way of providing this secret

into the container? So the question is, can I have a way of passing a secret, real secret password to the container, not in the container as it is right now. I made a proposal to the team that is maintaining the Docker system to have a third option. So I mentioned that you can either pass a password

or tell the container to generate a password. The third option should be get a password from a file, which at the moment is not available unless you modify the Docker file itself. So it can be done, it's not so difficult to do, but it requires the team to take action.

So at the moment, you can do this using deployment skits, but it's not going to be 100% secure. The second way that you can pass options is using a volume file. A volume file is something that resides

on your host operating system and is passed to MySQL. In this case, I have a minimal mycnf that I call minimal.cnf. I have only three things here, user equals MySQL, logbin, and server ID.

So what I do, I say the same thing that I did before, but in addition, I say minus V means use this volume and I gave the path of my minimal file and the path of the file that I want to be replaced inside the container.

This way, instead of reconfiguring the server like I would do with puppet shift in a virtual machine, I reconfigure the server at runtime. So this server will always be born with the option that I want.

And if I want to inspect the container, remember, this is a Linux machine, so I can enter inside. I can use this command, docker exec. Exec means execute something inside the container. Minus PI means is a terminal interactive and the name of the container

and what I want to execute. In this case, I want to execute a bash shell. Inside the bash shell, I run MySQL and I inspect. This is what I wanted. I wanted the server ID to be 100 and this is what is happening. You will see when you unload the slides

that there will be online later this evening that there is in GitHub a project that is called MySQL Replication Samples and if you go to GitHub and look for DataCharm, you will find it and there is a lot of scripts

to deploy MySQL in containers that you can try on. So I have two minutes more that I want to use for demo.

I'm going to show you the deployment of three MySQL containers in replication using a script.

So what you see in the screen now is the deployment of the containers. The containers are just being deployed. Now I wait 10 seconds for the installation to finish inside the containers and then I start querying the containers. Are you okay, yes or no?

And eventually one of those will say yes, no. Come on, don't do this to me.

What can I say? Oh, okay. It was a bit shy. So now the deployed replication is done. I create a table and set something inside. Sleep in 10 seconds just to give time

to replication to work and then I check if replication is okay, meaning that the slaves have received the data and they do. So exit code is zero. So the reason why this was a bit slower than usual

is because I'm using this inside the Mac of the system. And remember, this is not like a Linux host. Docker here is running inside the virtual machine. Nonetheless, everything ran in one minute and a half.

Question? I talk about the external storage that you do with the volume. The same thing that I did for the configuration file, I do with the data directory. I cannot do this with the Mac because it's a virtual machine. I can do it with Linux where I say

instead of using the data directory inside the container, use the virtual machine that is in this path. And this is what they do. If you use the scripts that are in GitHub, they will do exactly that. So with this, thanks a lot.

And more questions? One. So talking about external data directory, as I understand, if you upgrade MySQL binaries, you might need to do something to upgrade your data, some schema in the table set MySQL itself uses. Packages that get shipped with distributions

do that automatically with a bunch of scripts. If I'm using MySQL container, is it gonna do that for me or do I have to upgrade my data for the new binary myself? The upgrade software will work the same that they work with regular data. Because when you use a container,

basically the Docker has full control of the operating system. So the data will be changed the same way that you would do with a regular MySQL. Maybe you need to do something before installing the container.

This is what you were asking. Yes. No, it doesn't do that before. You need to do something external. And with this, I leave you with that.