Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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


            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 = () => (
             <admin restclient="{jsonServerRestClient('http://jsonplaceholder.typicode.com')}">
                <resource name="posts" list="{PostList}">
              </resource></admin>
            );

            export default App;

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


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

            export const PostList = (props) => (
              <list {...props}="">
                <datagrid>
                  <textfield source="id">
                  <textfield source="title">
                  <textfield source="body">
                </textfield></textfield></textfield></datagrid>
              </list>
            );

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

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

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


            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: Прописываем у ролей зависимости

Резюме

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

Ссылочки

Видео с шарингом экрана по этой презентации
Проект, который мы деплоили
Деплой скрипты
Best practices по ансиблу
В качестве упражнения можете повторить все, что мы делали на стадиях stage_0 и stage_1 на своем собственном хосте

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

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