Modern administration, i.e. Infrastructure as a code

We won’t discover America if we say that the larger the IT infrastructure, the greater the challenges in managing it. However, there are ways to simplify work worth exploring. If you have already had to deal with large infrastructures, you may have heard of the concept of DevOps, of which the concept of infrastructure-as-code is a part.

The DevOps working methodology (more on this subject can be found here) is about simplifying processes related to IT infrastructure management by automating it.

But let’s start with this

What is Infrastructure as a code?

To put it simply, Infrastructure as code (programmable infrastructure) is to write scripts or applications that support the infrastructure configuration process, instead of always making all settings manually. This means writing code (using high level languages or any declarative language) to manage configurations and automate infrastructure preparation.

But the thing is not only in scripts. Did you know that you can fully include the infrastructure configuration process in the code of your applications? However, you should not confuse Infrastructure as a code with infrastructure automation, which consists only in replicating steps and repeating this process on other servers.

Tools

Working with the Infrastructure as a code method, we use tools that are more widely used in the DevOps approach, for example:

• Vagrant
• Ansible
• Docker
• Chef
• and Puppet.

There are many ways to achieve the desired result – you can choose one tool, you can also combine them. This gives you the ability to automate basically everything that can be done manually and that is related to the infrastructure layer and the operating system layer. Even if the infrastructure already exists, you can use these tools to run even more scripts, even BAT files.

Programming not only in the hands of developers

Configuration by means of Infrastructure-as-code can be done by the administrator, but also by the programmer. This is quite a significant difference compared to the traditional manual approach, where the configuration was done only by administrators. Nowadays, the infrastructure can be built and managed by programmers and testers.

In the case of web programming, we are more and more often dealing with programmers who build such things as deploy.php. In this way they create an infrastructure on which the whole application will work. Writing a script begins with the creation of virtual machines and ends with a pull request from the source repository.

Advantages

What are the benefits of managing infrastructure as a code? There are several of them and that is significant:

• saves time,
• allows for repeatability of tasks. Deployments can be more than just copying resources and running code. They can also be infrastructure. For each implementation, a new set of infrastructure is created, on which the code is launched. Thanks to that we will avoid pollution of the already known phenomenon – “strange, it works for me”,
• scripts can also be used as documentation for infrastructure applications, which means that other people will also be able to benefit from the fruits of your work,
• we have a plan for future implementations. Through the fact that all activities are initiated by scripts – we have a specific point from which we can always start. If the scripts are properly written, you can run them everywhere: in private, public, hybrid cloud, on your own server – it doesn’t matter. For example: if we have several projects with different purposes, we can run them in specific clouds. If necessary, we create an integrated test cloud that is separated from the production cloud, which in turn is separated from the beta test cloud,
• facilitates communication. This is not an essential aspect, but sometimes saves a lot of time and frustration. Configuring using Infrastructure-as-code gives us the ability to communicate information about complete implementations, code and infrastructure, instead of sending difficult to decipher screenshots and bug descriptions,
• recording of changes. By using version control in the infrastructure code, you can easily track all changes that have occurred in our environment. This makes it easy to view configuration changes and get to the last working version in case of a problem,
• Linux. All these capabilities are available on the Linux infrastructure.

Example

We can do this automation with Ansible. We can install mysql-server on a remote machine (server), which ensures that mysql works, creates a user with a password, removes the test database, creates ansible_example database, copies sql dump to the machine and restores it to ansible_example database. Example code that will execute it:

---

- name: Installing MySQL
  yum: name=mysql-server state=latest

- name: Starting MySQL
  service: name=mysqld state=started enabled=yes

- name: Delete anonymous MySQL server user for localhost
  action: mysql_user user="" state="absent"

- name: Delete anonymous MySQL server user
  mysql_user: name='' host={{ item }} state=absent
  with_items:
    - "{{ ansible_hostname }}"
    - "{{ inventory_hostname }}"
    - 127.0.0.1
    - ::1
    - localhost

- name: Remove the MySQL test database
  action: mysql_db db=test state=absent

- name: Change root user password on first run
  mysql_user: login_user="root"
              login_password=""
              name="root"
              password="{{ mysql_root_passwd }}"
              priv=*.*:ALL,GRANT
              host={{ item }}
  with_items:
    - "{{ ansible_hostname }}"
    - 127.0.0.1
    - ::1
    - localhost

- name: Create my.cnf file with root passwd credentials
  template: src=my.cnf.j2 dest=/root/.my.cnf owner=root group=root mode=0600

- name: Configuring MySQL
  copy: src=my.cnf dest=/etc/my.cnf
  notify: restart_mysqld

All these actions are performed automatically when you start our playbook. No matter how many times we run it, if the required task has already been completed on the machine, it will not be done again. In other words, this script ensures that the machine is in the desired state all the time.

Challenges

Each stick has two ends. Here are some fascinating things:

• What to do if you are dealing with multi-layered applications?
• How to add a network and security component without experiencing a real nightmare? Developers are trying to get around this problem by dealing with these issues elsewhere,
• It is necessary to plan the infrastructure in advance in order to select the right tools,
• selection of tools. There are many of them and each of them has rich functionality. And this requires learning, often specialization, which in some cases can be an impenetrable barrier,
• how to plan actions if all applications are PaaS or are a combination of PaaS and infrastructure (whether in the cloud or on a server located there). You should consider writing several separate scripts,
• poorly performed configuration – can be duplicated on all servers,
• Situations where changes to the server configuration are made only on the machine (for example: by quick fixes, without making changes to the original template), the server configuration is different from the template configuration. And this can happen often if we do not impose ourselves a discipline in this area immediately.

Although Infrastructure as a code is not yet an ideal working method, it is still being developed dynamically and it is definitely worth trying. Given the current pace of evolution of this topic over the next year, perhaps two more significant changes are to be expected in order to facilitate its use. Indeed, it will become so popular that it will be surprisingly outdated form of manual configuration. So what to wait for?