Before we do this, make sure that you have a service that you want to deploy. To keep things simple, I followed the spring boot tutorial on making a restful web service. It was quick and the app worked like a charm. As usual, I went a bit extra and made my app return a stubbed list of users. You don’t have to. Make sure you have a
/healthcheck endpoint and another endpoint that you can test with. In my case, I have
/users which returns a list of users.
All righty then. Lets get a high level overview of what things are and how they are going to work. But before we do that, lets go through a quick real-ish life scenario.
Say you have a service that you have deployed onto AWS. Now you have a newer version of that service that you’d like to test. Since you never know if something works without actually trying it out, normally, after exhaustive testing in staging and other environments, you’d deploy that service into production to all your users. But ah ha! That one guy in your team forgot that one test case which made it blow up which means every single user of yours is now seeing error pages everywhere. This is bad so you roll it back to the previous version. Doesn’t sound too bad yet but by the time you do this, you’d have lost a couple of hours in time which would translate into actual money lost to the company which could eventually make a dent in your end of the year bonus.
Deploying applications is a complex task. You have to create some VMs, be it on DigitalOcean or AWS, download and install necessary prerequesites and then deploy your application. It would be easy if it were to end there, however, it doesn’t.
Following this you have application maintenance which includes deploying updated versions of your application in addition to other things like bug fixes. And this is where the real complexity starts. Your updated version might need another dependent application to be installed which in turn might need a version of some random tool to be upgraded. You did what was necessary but then you find out that the deployment of the updated application failed because you forgot to do that one null check in some corner of your application. So frantically you download the previous version of your application and try to restore it only to find that it doesn’t work anymore since you upgraded that random tool to support your newer application.
While all this is happening either your entire application is unavailable because your application is single instance or if it is indeed multi-instance split by a loadbalancer, all the other instances are being stressed out because one of the node is down.
And now you are thinking. Well, there has to be a better way.
Well my friend, there is.
Lets start off by deploying a single MySQL DB instance. For this, we’re going to use the default mysql image from docker hub. In order to deploy anything to CoreOS, you need to first create a service file. Here’s one for the MySQL that we’re going to deploy.
Description=MySQL database for wordpress
ExecStartPre=-/usr/bin/docker stop wpdb
ExecStartPre=-/usr/bin/docker rm wpdb
ExecStartPre=-/usr/bin/docker pull mysql:latest
ExecStart=/usr/bin/docker run -e MYSQL_ROOT_PASSWORD=glory86 --name wpdb -t mysql:latest
Save that file as
wpdb.service. Lets examine that file. As you can see, the file is split into three distinct sections.
X-Fleet. The Unit section tells CoreOS, or more specifically
fleet, what this service is about and what it is for. Since this one is quite simple, we only have a
Description here. Continue reading