Nowoczesne administrowanie, czyli Infrastruktura jako kod

Nie odkryjemy Ameryki jeśli powiemy, że im większa infrastruktura IT, tym większe wyzwania w zarządzaniu nią. Są jednak sposoby uproszczenia pracy warte zgłębienia. Jeśli miałeś już do czynienia z dużymi infrastrukturami, to zapewne słyszałeś o pojęciu DevOps, którego częścią jest właśnie pojęcie Infrastruktury-jako-kodu.

W metodyce pracy DevOps (z jęz. ang. Development and Operations, więcej na ten temat możesz poczytać tutaj) chodzi o uproszczenie procesów związanych z zarządzaniem infrastrukturą IT poprzez jej automatyzację.

Zacznijmy jednak od tego

Czym jest Infrastruktura jako kod?

Mówiąc najprościej, Infrastruktura jako kod (z jęz. ang. Infrastructure as code, programmable infrastructure) to pisanie skryptów lub aplikacji wspomagających proces konfiguracji infrastruktury, zamiast każdorazowego dokonywania wszystkich ustawień manualnie. Oznacza to napisanie kodu (za pomocą języków wysokiego poziomu lub każdego języka deklaratywnego) do zarządzania konfiguracjami, oraz zautomatyzowania przygotowania infrastruktury.

Ale rzecz jest nie tylko w skryptach. Wiedziałeś, że można w pełni uwzględnić proces konfiguracji infrastruktury w kodzie Twoich aplikacji? Nie należy jednak mylić Infrastruktury-jako-kodu z automatyzacją infrastruktury, która polega tylko na wielokrotnym replikowaniu kroków oraz powtarzaniu tego procesu na innych serwerach.

Narzędzia

Pracując metodą Infrastruktury-jako-kodu używamy narzędzi, które są szerzej wykorzystywane w podejściu DevOps, na przykład:

• Vagrant
• Ansible
• Docker
• Chef
• oraz Puppet.

Dróg do osiągnięcia oczekiwanego rezultatu jest wiele – można wybrać jedno narzędzie, można również je łączyć. Daje to możliwość zautomatyzowania w zasadzie wszystkiego, co można zrobić ręcznie, a co jest związane z warstwą infrastruktury oraz warstwą systemu operacyjnego. Nawet jeśli infrastruktura już istnieje, to można wykorzystać te narzędzia do uruchomienia jeszcze większej ilości skryptów, nawet plików BAT.

Programowanie nie tylko w rękach programistów

Konfigurowaniem za pomocą Infrastruktury-jako-kodu może zająć się administrator, ale także programista. To dość istotna różnica w porównaniu do tradycyjnego, manualnego podejścia, gdzie konfigurację wykonywali tylko administratorzy. W obecnych czasach infrastruktura może być budowana i zarządzana przez programistów oraz testerów.

W przypadku programowania webowego, coraz częściej mamy do czynienia z programistami, którzy budują takie rzeczy jak deploy.php. Tworzą w ten sposób infrastrukturę, na której będzie działała cała aplikacja. Pisanie skryptu zaczyna się tu od stworzenia maszyn wirtualnych, a kończy się na pull request z repozytorium źródła.

Zalety

Jakie korzyści przynosi zarządzanie Infrastrukturą jako kodem? Jest ich kilka i to znaczących:

• oszczędza czas,
• pozwala na powtarzalność zadań. Wdrożenia mogą być czymś więcej, niż tylko kopiowaniem zasobów i uruchamianiem kodu. Mogą też być infrastrukturą. Do każdego wdrożenia powstaje nowy zestaw infrastruktury, na której uruchamiany jest kod. Dzięki temu unikniemy zanieczyszczeń i tak znanego wszystkim zjawiska – „dziwne, u mnie działa”,
• skrypty mogą posłużyć także jako dokumentacja dla aplikacji infrastruktury, co oznacza że inne osoby też będą mogły korzystać z owoców twojej pracy,
• mamy plan dla przyszłych wdrożeń. Poprzez fakt, że wszystkie działania są inicjowane przez skrypty – mamy konkretny punkt, od którego zawsze możemy zacząć. Jeśli skrypty są prawidłowo napisane, można je uruchomić wszędzie: w chmurze prywatnej, publicznej, hybrydowej, na własnym serwerze – nie ma to znaczenia. Przykładowo: jeśli mamy kilka projektów o różnym przeznaczeniu, to możemy je uruchomić w konkretnych chmurach. Jeśli jest taka potrzeba, to tworzymy zintegrowaną chmurę testowania, która jest oddzielona od chmury produkcyjnej, a ta z kolei jest oddzielona od chmury przeznaczonej do beta testowania,
• ułatwia komunikację. Nie jest to zasadniczy aspekt, ale pozwala niekiedy zaoszczędzić dużo czasu i frustracji. Konfigurowanie za pomocą Infrastruktury-jako-kodu daje nam możliwość przekazania informacji na temat kompletnych wdrożeń, kodu oraz infrastruktury, zamiast przesyłania trudnych do rozszyfrowania zrzutów ekranu oraz opisów bugów,
• rejestrowanie zmian. Dzięki zastosowaniu kontroli wersji w kodzie infrastruktury, można w łatwy sposób śledzić wszystkie zmiany które zaszły w naszym środowisku. Ułatwia to przeglądanie zmian konfiguracji i dotarcie do ostatniej działającej wersji, w razie gdyby wystąpił jakiś problem,
• Linux. Wszystkie te możliwości są dostępne na infrastrukturze linuksowej.

Przykład

Możemy dokonać takiej oto automatyzacji za pomocą Ansible . Możemy zainstalować mysql-server na zdalnej maszynie (serwerze), co zapewnia że mysql działa, tworzy użytkownika z hasłem, usuwa testową bazę danych, tworzy bazę danych ansible_example, kopiuje sql dump na maszynę i przywraca ją do bazy danych ansible_example. Przykładowy kod, który to wykona:

---

- 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

Wszystkie te działania wykonywane są automatycznie, kiedy uruchamiamy nasz playbook. Nie ważne ile razy byśmy go uruchamiali, jeśli wymagane zadanie zostało już wykonane na maszynie, to nie będzie ono ponownie wykonane. Innymi słowy – ten skrypt dba o to, by maszyna cały czas znajdowała się w pożądanym przez nas stanie.

Wyzwania

Każdy kij ma dwa końce. Oto kilka frapujących kwestii:

• co zrobić, jeśli mamy do czynienia z wielowarstwowymi aplikacjami?
• jak dodać komponent sieci i bezpieczeństwa nie przeżywając przy tym prawdziwego koszmaru? Programiści starają się obejść ten problem zajmując się tymi kwestiami w innym miejscu,
• trzeba wcześniej zaplanować infrastrukturę, aby właściwie dobrać narzędzia,
• dobór narzędzi. Jest ich wiele i każde posiada bogate funkcjonalności. A to wymaga nauki, często specjalizacji, co w niektórych przypadkach może być barierą nie do przejścia,
• jak zaplanować działania, jeśli wszystkie aplikacje są PaaS albo są kombinacją PaaS i infrastruktury (czy to w chmurze, czy na serwerze znajdującym się miejscu). W takim przypadku trudniej jest stworzyć jeden skrypt obejmujący je wszystkie.Trzeba rozważyć napisanie kilku oddzielnych skryptów,
• źle przeprowadzana konfiguracja – może zostać powielona na wszystkich serwerach,
• sytuacja kiedy zmiany konfiguracji serwera są wprowadzane tylko na maszynie (na przykład: poprzez szybkie poprawki, bez wprowadzania zmian do oryginalnego szablonu), konfiguracja serwera różni się od konfiguracji szablonu. I to się może często zdarzać, jeśli od razu nie narzucimy sobie dyscypliny w tym zakresie.

Mimo że Infrastruktura jako kod nie jest jeszcze idealną metodą pracy, to cały czas jest dynamicznie rozwijana i zdecydowanie warto jej spróbować. Biorąc pod uwagę obecne tempo ewolucji tego tematu w ciągu najbliższego roku, może dwóch – należy spodziewać się dalszych znaczących zmian idących w kierunku ułatwienia korzystania z niej. Ba, stanie się ona na tyle popularna, że dziwić będzie przestarzała forma manualnej konfiguracji. Na co więc czekać?