CircleCI: обзор Continuous Integration сервиса

Автор: | 31/05/2018

CircleCI – система для сборки и деплоя, аналогичная Travis CI (Github), и работающая по тем же принципам – к CircleCI-аккаунту подключаются репозитории (в отличи от Travis – к CircleCI можно добавить любой репозиторий, в т.ч. Bitbucket), билды выполняются в контейнерах или вирутальных машинах, уведомления о результатах билда можно получить на почту или через интеграцию со Slack/HipChat etc, а код задеплоить в AWS ECS, S3, Heroku средствами самого CircleCI, или в любое другое окружение, используя скрипты. Обзор и документация – тут>>>.

CircleCI доступна как в облаке, так и в виде self-hosted решения. При этом в облаке предоставляется free-план, который позволяет использовать 1 контейнер и 1 одновременный билд.  Подробнее – тут>>>.

Рассматриваю его как замену Jenkins для выполнения настроек RTFM (см. посты про миграцию>>>, которую пока забросил из-за новой работы, но хочу таки закончить), т.к. билды мне требуются редко, и держать отдельную машину под Jenkins, да ещё и t2.micro как минимум, с его 10 уе/мес – не хочется. Хотя, как вариант – можно использовать AWS spot-инстансы, но зачем, если можно использовать готовое решение, и не иметь головной боли с апдейтами Jenkins-а?

В этом посте – беглое знакомство с CircleCI и пример запуска ansbile-playbook для теста.

Начало работы

Регистрируемся через страницу регистрации тут>>>, выбираем Public repos only:

 

После авторизации попадаем в CircleCI дашборд:

Добавление проекта

Переходим в Add Projects, выбираем проект, который будем билдить:

Есть у меня репозиторий tests, как раз для таких целей – добавляем его:

Circle сразу подсказывает пример файла для запуска проекта, внизу:

Собственно мне от CircleCI требуется запускать только Ansible задачи – никакого кода собирать не надо.

Настройка репозитория

Документация по config.ymlтут>>>.

Настраиваем репозиторий – добавляем в него каталог .circleci:

[simterm]

16:55:55 [setevoy@setevoy-arch-home ~/Work/RTFM/Github/tests] [master*]  
$ mkdir .circleci

[/simterm]

Добавляем файл .circleci/config.yml:

version: 2
jobs:
  build:
    docker:
      - image: williamyeh/ansible:debian9
    steps:
      - checkout
      - run:
          name: Greeting
          command: echo Hello, world.
      - run:
          name: Print the Current Time
          command: date
      - run: 
          name: Ansible ping
          command: ansible-playbook ping.yml

Меняем image – запускаем контейнер из образа williamyeh/ansible:debian9 (хотя пока без понятия на какой ОС запускаются контейнеры), и добавляем команду на запуск ansbile-playbook для теста.

Добавляем, коммитим, пушим:

[simterm]

$ git add .circleci/config.yml && git commit -m "CircleCI test" && git push

[/simterm]

Жмём Start building и первый билд ожидаемо фейлится:

ОК, поторопился, но зато видно, что Circle подхватил файл конфига, и отслеживает репозиторий – хорошо.

Теперь добавляем ping.yml:

- hosts: all
  tasks:
  - ping:

Обновляем вызов Ansible:

...
    command: ansible-playbook -i "localhost," -c local ping.yml

Коммитим, пушим – и с третьей попытки билд прошёл:

Переменные окружения

Тут я нашёл ОС, на которой запускаются контейнеры: переходим в настройки проекта > Build environment:

(Ubuntu 12 и 14, серьёзно? Где 16, где 18?)

И переменные в Environment Variables:

Через переменные можно пробовать передавать AWS access/secret ключи, или пароли к Ansible vault-ам, хотя хранить приватные данные, даже зашифрованные, в публичном репозитории Github – идея очень так себе, так что надо будет думать как подключить в один билд репозитории и Github, и приватный репозиторий Bitbucket, в котором у меня хранятся, например, SSH-ключи, которыми пользуется Ansible для доступа к серверам. Ну – или выносить всё в Bitbucket, но вот этого тоже не хочется…

В общем – первый билд получился, можно пробовать использовать CircleCI как замену Jenkins.

В целом – всё выглядит достаточно интересно, хотя интерфейс Travis мне нравился больше. Зато – тут нет привязки к Github-only репозиториям.