Tsuru, transforming the IT department into a service provider
With extensive experience in production environments, first in unix environments and later with linux, I have seen a transformation in the way that the datacenters are managed and also how, from the production departments, the applications are implemented.
Bare-metal
In the pre-virtualization era, most applications were implemented in such a way that each application had an economic allocation to have its own server. This made the DataCenters grow exponentially to the growth of computer applications that were introduced in companies, something unsustainable since the cost and under-use of the servers was very high. Maintenance was very expensive and even implementing high availability solutions sometimes required doubling or tripling the number of servers required for an application.
Virtualización
Then came the virtualization time, in which the cost per server was drastically reduced since the use of server resources was optimal, being able to host as many virtual machines on the machine as the cpu and memory resources allowed. In addition, the level of isolation within the host of the VMs is very successful. But this also has its disadvantages, since to host a LAMP in a virtual machine with its apache-php-mysql, we also need the whole part of the operating system, with its kernel, libc, etc …, consuming memory and more resources . KVM tries to mitigate this problem with the use of [KSM] ( http://www.linux-kvm.org/page/KSM) (Kernel Samepage Merging) by making the memory pages shared between virtual machines be merged to optimize usage. memory in the host.
Paas - Platform as a service
In many companies they have bet firmly for years on Free Software, something that allowed very rapid changes in the infrastructure without the licensing costs that you have with proprietary systems. This requires that the IT department staff grow rapidly with Linux technicians and developers, who also need to create their applications quickly and although there are ** IaaS (Infrastructure as a Service) ** solutions with self-service portals such as the famous ** OpenStack **, this requires that either the administrator install the entire stack for the application to work or the developer knows how to install it and is in charge of doing it, something that he does not always have to know how to do, in addition to that he would have to know very well the entire network and storage structure to be able to put your application in production. This in addition to being complicated, can take time away from the developer to meet his objectives.
A few years ago, the first platforms as a service appeared like [Heroku] ( https://www.heroku.com), which allowed the developer to deploy their application without having to know anything about the infrastructure behind it. That he needs a database or a rabbit-mq queue, since the system is exposed as a service so that he can use it within the app without having to know where those services are. In the same way, the system offers a series of languages or frameworks so that the developer can choose the one he likes the most or the one that suits him the most at that moment, python, nodejs or java.
If you want to set up a private Paas I would recommend you by [TSURU https://tsuru.io] ( https://tsuru.io) for the following reasons:
- The main method of interacting with tsuru is ** git **, so the developer doesn’t have to learn anything new
- The final product of a deploy within tsuru is a docker image, which at the moment has been placed at the head of the container systems on the market.
- Tsuru allows to have a cluster of docker nodes to run the applications and thus be able to scale horizontally and even autoscaling the apps
- New platforms or services are easy to create and include in the system.
The complete product documentation can be found on the tsuru website [http://tsuru.readthedocs.org] ( http://tsuru.readthedocs.org) and in order not to repeat the same thing that is in the documentation, I am going to teach how to deploy an application made in nodejs downloaded from github, it’s called [mongo-express] ( https://github.com/andzdroid/mongo-express) and it’s a frontend made in nodejs for mongodb. In order to perform the installation we need a complete tsuru environment, in addition to the tsuru-client and tsuru-admin clients
- Download the application from github
$ git clone https://github.com/andzdroid/mongo-express.git && cd mongo-express
- With the tsuru client, we create the application with the platform we want to use, in our case, nodejs
$ tsuru app-create mongo-express nodejs
- Now we can see the application information, such as the assigned git repository and the url through which we can access the service.
tsuru app-info
Application: mongo-express
Repository: git@tsrmgr.example.com:mongo-express.git
Platform: nodejs
Teams: admin
Address: mongo-express.tsuru.example.com
Owner: admin@example.com
Team owner: admin
Deploys: 0
Pool: prod
App Plan:
+---------------+--------+------+-----------+--------+---------+
| Name | Memory | Swap | Cpu Share | Router | Default |
+---------------+--------+------+-----------+--------+---------+
| autogenerated | 0 MB | 0 MB | 100 | | false |
+---------------+--------+------+-----------+--------+---------+
- To start our app we need a Procfile file and we also copy the config.defaults.js file to config.js. We edit config.js to adapt it to our installation, they change the server and especially changing the site.port to port 8888, which is the one that tsuru expects to listen to your application
echo "web: node app" > Procfile
cp config.default.js config.js
git add Procfile
gtt add -f config.js
git commit -am "add Procfile and config.js"
- With the information we have asked before we see that the git repo to use is git@tsrmgr.example.com: mongo-express.git so we must add it to the repo
git remote add tsuru git@tsrmgr.example.com:mongo-express.git
- After adding the Procfile and config.js files to the repo, we push to tsuru
root@tsrmgr:~/mongo-express# git push tsuru master
Counting objects: 22, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (19/19), done.
Writing objects: 100% (22/22), 9.60 KiB | 0 bytes/s, done.
Total 22 (delta 10), reused 0 (delta 0)
remote: tar: Removing leading \`/' from member names
remote:
remote: ---- Building application image ----
remote: ---> Sending image to repository (0.05MB)
remote: ---> Cleaning up
remote:
remote: ---- Starting 1 new unit ----
remote: ---> Started unit 7d60e37be6...
remote:
remote: ---- Binding and checking 1 new units ----
remote: ---> Bound and checked unit 7d60e37be6
remote:
remote: ---- Adding routes to 1 new units ----
remote: ---> Added route to unit 7d60e37be6
remote:
remote: OK
To git@tsrmgr.example.com:mongo-express.git
\* \[new branch\] master -> master
Now if we rerun tsuru app-info -a mongo-express we will see our application raised in one of the docker nodes
root@tsrmgr:~/mongo-express# tsuru app-info
Application: mongo-express
Repository: git@tsrmgr.example.com:mongo-express.git
Platform: nodejs
Teams: admin
Address: mongo-express.tsuru.example.com
Owner: admin@example.com
Team owner: admin
Deploys: 4
Pool: prod
Units: 1
+------------+---------+--------------------+-------+-------------+
| Unit | State | Host | Port | IP |
+------------+---------+--------------------+-------+-------------+
| 15f823cf0b | started | tsurunode01 | 32829 | 172.17.0.84 |
+------------+---------+--------------------+-------+-------------+
App Plan:
+---------------+--------+------+-----------+--------+---------+
| Name | Memory | Swap | Cpu Share | Router | Default |
+---------------+--------+------+-----------+--------+---------+
| autogenerated | 0 MB | 0 MB | 100 | | false |
+---------------+--------+------+-----------+--------+---------+
Now you can access the url that appears in the Address to see the application running
http://mongo-express.tsuru.example.com
With tsuru we can take full advantage of the hardware since each app only has the right processes to work within the docker container
root@tsrmgr:~/mongo-express# tsuru app-shell
root@43cc63f1d59e:/# ps -ef
UID PID PPID C STIME TTY TIME CMD
ubuntu 1 0 0 jul09 ? 00:00:00 /usr/bin/python /usr/local/bin/tsuru\_unit\_agent http://tsrmgr.example.com:8080 e9b847909a51f4e0b79382ecac672efd46cc0beb mongo-express /var/li
ubuntu 9 1 0 jul09 ? 00:00:58 /home/application/.circus\_env/bin/python /home/application/.circus\_env/bin/circusd /etc/circus/circus.ini --log-output /var/log/circus/circus.
ubuntu 23 9 0 jul09 ? 00:00:00 /home/application/.circus\_env/bin/python -c from circus import plugins;plugins.main() --endpoint tcp://127.0.0.1:5555 --pubsub tcp://127.0.0.1
ubuntu 24 9 0 jul09 ? 00:00:00 /home/application/.circus\_env/bin/python -c from circus import plugins;plugins.main() --endpoint tcp://127.0.0.1:5555 --pubsub tcp://127.0.0.1
ubuntu 27 9 0 jul09 ? 00:00:32 /home/application/.circus\_env/bin/python -c from circus import plugins;plugins.main() --endpoint tcp://127.0.0.1:5555 --pubsub tcp://127.0.0.1
ubuntu 28 9 0 jul09 ? 00:00:09 /home/application/.circus\_env/bin/python -c from circus import plugins;plugins.main() --endpoint tcp://127.0.0.1:5555 --pubsub tcp://127.0.0.1
ubuntu 31 9 0 jul09 ? 00:00:00 node app
root 54 0 1 22:13 ? 00:00:00 bash -l
root 68 54 0 22:13 ? 00:00:00 ps -ef