Go to Puppet or how not to spoil the soup
Good day to all.
I work as a system administrator in a small company myhotspot , engaged in various developments in the field of IT, including ruby ​​on rails. Naturally, you often have to install and administer virtual servers, for which we successfully use Puppet. On Habré already wrote about Puppet ( How to become a puppeteer or Puppet for beginners or Puppet under load ), but did not describe what I think is very important to say. The essence of the problem that I want to describe in the process of transition to an automatic server configuration management system called Puppet. About how it is easier to do than to be guided, what to fear and how to live on.
Many have already heard of him, but few use it. Many will say that it is not needed, more than once I have already heard that there are deployment scripts written by our elder Uncle Vasya, or chef, or python Fabric, in the end a person cannot be replaced by anything and I will do everything myself! Each of these opinions is correct, but we just decided that we need to develop and try to maximally automate and simplify the installation, management of servers using Puppet. Another equally important focus in favor of Puppet was that we have a ruby-oriented company and our programmers can help administrators in any given situation.
Imagine a company having 10-12 virtual locks on each of which there are 5-6 projects spinning with different databases (mysql, mongo, postgres) and you need to constantly purchase and install new virtual projects. Add the need to backup all this and get a fairly large amount of work. And having read about Puppet and its capabilities, having gathered your courage, you decided to transfer all servers to Puppet. Where to begin? How to act so that the architecture of your servers is as efficient and safe as possible? I will not talk about how puppet works and how it works (I already had articles on this topic and I believe you know how to use Google), I’ll tell you a few tips on how to switch to it will be painless and quick.
The first thing to do is to check the documentation of your servers. If you have not done it yet, I strongly recommend it to be done, which will make life easier for you and your fellow programmers. The documentation should help you understand what Puppet modules you need (rbenv, nginx) and what to do if you are writing manifests for Puppet. Documentation should contain the most detailed information about what, where, on which server is installed and how the server itself is configured.
')
Writing the form “nginx from ppa” will already help you understand that in the case of Puppet (for example, include nginx) you should consider the possibility of automatically installing nginx from ppa. We need a plan to develop which manifestos in the first place and what will be needed in the future.
1) Puppet master should be on the most fault-tolerant and secure server that you have. Why? Because Puppet master contains information about all your servers, what is located, passwords and the most important thing is that with the help of puppet an attacker can execute exec with any command from root on any master connected to Puppet. We keep it on amazon on the smallest and cheapest (in 1 year it is free) virtual machine and it is backed up daily.
2) Advises to keep the Puppet directory with configs / manifests (for example / etc / puppet for ubuntu) in a truecrypt container. What for? All the same, in order to ensure safety. In case of a reboot or unauthorized password or public key penetration, you close the container and that's it, rejoice that your servers connected to the puppet master are still alive.
So, you installed Puppet master, made a script for its backups and keep all configs / manifests in the container, then it’s time to connect the Puppet agent to the server. The first thing you need to do is install a clean, small virtual test server! Implementing a production manifest describing, for example, installing apache is better only after long trials. Thanks to this you can avoid a lot of trouble and facilitate the development of manifests / modules / scripts for Puppet master. As for the scripts, if you have scripts to install something (for example, mysql-server or mongodb) do not rush to throw them in the trash! The most appropriate transition from your old administration method to the new one will be storing these scripts on the Puppet master and then executing them on the client using Puppet master and exec ...
But what about github? Bitbucket? Yes, these are reliable and correct paths, but unfortunately there are various vulnerabilities on them that allow you to access your repository with Puppet manifests. Therefore, I highly recommend keeping all configs / manifests on your git server.
At the moment, our company is preparing its public repository with ready-made modules, documentation, and server management to make life easier for the rest of the system administrators.
I work as a system administrator in a small company myhotspot , engaged in various developments in the field of IT, including ruby ​​on rails. Naturally, you often have to install and administer virtual servers, for which we successfully use Puppet. On Habré already wrote about Puppet ( How to become a puppeteer or Puppet for beginners or Puppet under load ), but did not describe what I think is very important to say. The essence of the problem that I want to describe in the process of transition to an automatic server configuration management system called Puppet. About how it is easier to do than to be guided, what to fear and how to live on.
Why Puppet?
Many have already heard of him, but few use it. Many will say that it is not needed, more than once I have already heard that there are deployment scripts written by our elder Uncle Vasya, or chef, or python Fabric, in the end a person cannot be replaced by anything and I will do everything myself! Each of these opinions is correct, but we just decided that we need to develop and try to maximally automate and simplify the installation, management of servers using Puppet. Another equally important focus in favor of Puppet was that we have a ruby-oriented company and our programmers can help administrators in any given situation.
What is the problem?
Imagine a company having 10-12 virtual locks on each of which there are 5-6 projects spinning with different databases (mysql, mongo, postgres) and you need to constantly purchase and install new virtual projects. Add the need to backup all this and get a fairly large amount of work. And having read about Puppet and its capabilities, having gathered your courage, you decided to transfer all servers to Puppet. Where to begin? How to act so that the architecture of your servers is as efficient and safe as possible? I will not talk about how puppet works and how it works (I already had articles on this topic and I believe you know how to use Google), I’ll tell you a few tips on how to switch to it will be painless and quick.
Documentation
The first thing to do is to check the documentation of your servers. If you have not done it yet, I strongly recommend it to be done, which will make life easier for you and your fellow programmers. The documentation should help you understand what Puppet modules you need (rbenv, nginx) and what to do if you are writing manifests for Puppet. Documentation should contain the most detailed information about what, where, on which server is installed and how the server itself is configured.
')
Writing the form “nginx from ppa” will already help you understand that in the case of Puppet (for example, include nginx) you should consider the possibility of automatically installing nginx from ppa. We need a plan to develop which manifestos in the first place and what will be needed in the future.
Where is Puppet master?
1) Puppet master should be on the most fault-tolerant and secure server that you have. Why? Because Puppet master contains information about all your servers, what is located, passwords and the most important thing is that with the help of puppet an attacker can execute exec with any command from root on any master connected to Puppet. We keep it on amazon on the smallest and cheapest (in 1 year it is free) virtual machine and it is backed up daily.
2) Advises to keep the Puppet directory with configs / manifests (for example / etc / puppet for ubuntu) in a truecrypt container. What for? All the same, in order to ensure safety. In case of a reboot or unauthorized password or public key penetration, you close the container and that's it, rejoice that your servers connected to the puppet master are still alive.
Testing. We connect clients
So, you installed Puppet master, made a script for its backups and keep all configs / manifests in the container, then it’s time to connect the Puppet agent to the server. The first thing you need to do is install a clean, small virtual test server! Implementing a production manifest describing, for example, installing apache is better only after long trials. Thanks to this you can avoid a lot of trouble and facilitate the development of manifests / modules / scripts for Puppet master. As for the scripts, if you have scripts to install something (for example, mysql-server or mongodb) do not rush to throw them in the trash! The most appropriate transition from your old administration method to the new one will be storing these scripts on the Puppet master and then executing them on the client using Puppet master and exec ...
Own git server
But what about github? Bitbucket? Yes, these are reliable and correct paths, but unfortunately there are various vulnerabilities on them that allow you to access your repository with Puppet manifests. Therefore, I highly recommend keeping all configs / manifests on your git server.
At the moment, our company is preparing its public repository with ready-made modules, documentation, and server management to make life easier for the rest of the system administrators.
Source: https://habr.com/ru/post/164197/
All Articles