Говорим о новом

Как перестать беспокоиться о деплое и конфигах приложения c Ansible

Автор: Давыденков Михаил

Содержание

  • Суть
  • Мнение экспертов
  • Изучаем на практике. Вдохновляющая демка
  • Обзор нюансов ансибла и проекта ansible-deploys (шаринг рецептов между проектами)
  • Ссылочки

Суть. Ansible - это про автоматизацию рутины

arch1

В чем проблема?

Допустим мы делаем новый проект - супер крутые админки на реакте под ключ :)

Которые позволяют каждому клиенту видеть и редактировать все свои посты в твиттере.

Спросим экспертов :)

  • За сколько сторипоинтов вы сделаете список постов по готовому API?
  • А за сколько сторипоинтов вы сделаете так, чтобы все доехало на продакшн хост и заработало там?
  • А на 10 хостов для 10 клиентов?
  • А если на всех 10 хостах надо переодически обновлять node.js и другие зависимости?

И тут мы понимаем

Когда в процессе разработки появляется инфраструктура, то исчезает прозрачность

Чем больше хостов и зависимостей, тем дело хуже

arch1

В идеальном мире product developers ленивы и не повторяют одно и то же действие по 100 раз

arch1

Работаем мозгами, а не руками (но сначала все же немного руками)

Создаем новый проект на реакте 


            npm install -g create-react-app
            create-react-app test-admin
            cd test-admin/
            yarn add admin-on-rest
            yarn start
          

            // in src/App.js
            import React from 'react';
            import { jsonServerRestClient, Admin, Resource  } from 'admin-on-rest';

            import { PostList  } from './posts';

            const App = () => (
             
                
              
            );

            export default App;

* Господа фронтендеры, презентационный движок меня дискредитирует :) Я знаю, что компоненты - это константы и пишутся с большой буквы! :) 


            // in src/posts.js
            import React from 'react';
            import { List, Datagrid, TextField  } from 'admin-on-rest';

            export const PostList = (props) => (
              
                
                  
                  
                  
                
              
            );

* Господа фронтендеры, презентационный движок меня дискредитирует :) Я знаю, что компоненты - это константы и пишутся с большой буквы! :)

Ну вот и все :) проект готов!

Или нет? Что делать со сборкой?

arch1 

            yarn run build

Готовим сервер

  • Создаем себе пользователя на серверной машине
  • Подкладываем публичный ключ со своего мака на сервер в ~/.ssh/authorized_keys
  • Ставим питон интерпретатор на сервере 

          sudo add-apt-repository ppa:fkrull/deadsnakes
          sudo apt-get update
          sudo apt-get install python2.7
          sudo ln -sf /usr/bin/python2.7 /usr/bin/python

Лив кодинг session. Добавляем деплой к нашему проекту

Можно посмотреть в сорцы тут (ветки stage_0, stage_1, stage_2)

stage_0 (Деплой)

  • Создаем Inventory File - hosts
  • Создаем playbook - deploy.yml
  • Создаем роль - roles/deploy_frontend.yml
  • Подключаем роль к плейбуку - деплой написан 

            ansible-playbook -i hosts deploy.yml

stage_1 (Setup)

Ставим готовый пакет из репозитория ролей (ближайшая аналогия rubygems, npm, dockerhub) 


            ansible-galaxy install jdauphant.nginx

Держим зависимости вместе с самописными ролями 


            mv ~/.ansible/roles/jdauphant.nginx roles/
  • Пишем собственную роль copy_nginx_configs, которая будет подкладывать nginx config из вашего шаблона (copy_nginx_configs)
  • Создаем новый playbook setup.yml, куда подключаем написанные только что роли 

            ansible-playbook -i hosts setup.yml -K

stage_2 (Удобности и нюансы)

  • создаем папку vars , и выносим все различия между сценариями деплоя в переменные, прячем в vars пароли и энкриптим секреты
  • пишем Makefile, чтобы не запоминать сложные ключи и иметь возможность шарить переменные между задачами
  • игнорируем ошибки через ignore_errors (docker swarm init, например, кидает ошибку, если кластер уже создан)
  • регистрируем результаты linux команд через register, а через debug кидаем результат в output
  • если запутались в переменных - всегда есть strategy: debug для дебага свалившейся задачи (p vars)
  • используем with_items для работы с циклами, а также чтобы размножить шаблон с разными переменными
  • пользуемся become и become_user, а также ansible_become_pass, и не пользуемся ansible_become_user (т.к. это переменная, живущая на уровне connection и ее ничем не перебить)
  • разделяем sudo пользователей и deployer пользователей во избежание секьюрити проблем (а также sudo роли и не sudo роли)
  • смотрим ansible.cfg, читаем best-practices в доках
  • запускаем роли удаленно через дополнительный пакет ansible-toolbox(динамическая генерация плейбуков)
  • TODO: тестируем роли на вагранте включая проверки на идемпотентность (полезный эффект только при 1м прогоне)
  • TODO: Прописываем у ролей зависимости

Резюме

  • Ансибл - простой и понятный инструмент для малых и средних проектов
  • Можно постепенно автоматизировать процессы настройки серверов
  • Много решений уже написаны за вас умными людьми - пользуйтесь :)

Ссылочки

THE END