Successfully reported this slideshow.
Your SlideShare is downloading. ×

Как Vagrant и Chef ускорили разработку в несколько раз / Тимур Батыршин (Cinarra Systems)

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 40 Ad

Как Vagrant и Chef ускорили разработку в несколько раз / Тимур Батыршин (Cinarra Systems)

Download to read offline

Год назад у нас в компании еще никто специально не занимался серверами и их конфигурацией.

Был целый спектр проблем, обычных для такого случая:
* ручная выкатка новых версий на продакшн занимала несколько часов;
* большая часть времени программистов уходила на настройку своих окружений разработки и синхронизацию их между собой;
* везде на тестовых серверах стояли неизвестно какие версии, и из-за этого куча времени уходила на баги, которые могли быть уже исправлены несколько дней назад;
* неправильная конфигурация каких-то компонентов приложения приводила к неработоспособности приложения целиком.

Чтобы исправить положение мы сделали следующее:
* завернули всю конфигурацию в Chef;
* для управления конфигами приложений начали использовать augeas (у нас большие и часто меняющиеся конфиги;
* теперь ежедневно автоматически собирается образ сервера со всеми установленными и настроенными приложениями последней версии, из которого разработчики при помощи Vagrant могут создавать себе сервера по мере необходимости, не отвлекаясь на установку, обновление и настройку;
* Ежедневно Jenkins из того же образа Vagrant-ом поднимает сервера и прогоняет на них тесты.

Теперь наши разработчики спокойно спят ночами, вместо того, чтобы спешно фиксить баги.
Процесс разработки стал более предсказуемым. Скорость исправления багов возросла. Все счастливы.

Год назад у нас в компании еще никто специально не занимался серверами и их конфигурацией.

Был целый спектр проблем, обычных для такого случая:
* ручная выкатка новых версий на продакшн занимала несколько часов;
* большая часть времени программистов уходила на настройку своих окружений разработки и синхронизацию их между собой;
* везде на тестовых серверах стояли неизвестно какие версии, и из-за этого куча времени уходила на баги, которые могли быть уже исправлены несколько дней назад;
* неправильная конфигурация каких-то компонентов приложения приводила к неработоспособности приложения целиком.

Чтобы исправить положение мы сделали следующее:
* завернули всю конфигурацию в Chef;
* для управления конфигами приложений начали использовать augeas (у нас большие и часто меняющиеся конфиги;
* теперь ежедневно автоматически собирается образ сервера со всеми установленными и настроенными приложениями последней версии, из которого разработчики при помощи Vagrant могут создавать себе сервера по мере необходимости, не отвлекаясь на установку, обновление и настройку;
* Ежедневно Jenkins из того же образа Vagrant-ом поднимает сервера и прогоняет на них тесты.

Теперь наши разработчики спокойно спят ночами, вместо того, чтобы спешно фиксить баги.
Процесс разработки стал более предсказуемым. Скорость исправления багов возросла. Все счастливы.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (6)

Advertisement

Similar to Как Vagrant и Chef ускорили разработку в несколько раз / Тимур Батыршин (Cinarra Systems) (20)

More from Ontico (20)

Advertisement

Recently uploaded (20)

Как Vagrant и Chef ускорили разработку в несколько раз / Тимур Батыршин (Cinarra Systems)

  1. 1. Как Vagrant и Chef ускорили разработку в несколько раз Тимур Батыршин Cinarra Systems
  2. 2. Обо мне Инженер по эксплуатации в Cinarra Systems • Тимур Батыршин • timur@cinarra.com • @erthad
  3. 3. Cinarra Systems • Молодая международная компания • Строим платформу для мобильной рекламы
  4. 4. Ситуация год назад • Инфраструктурой еще никто не занимается • Более 10 сильносвязанных компонентов приложения • Много конфигов • Тесты зависят от данных
  5. 5. Проблемы • Долгий деплой • Сложность конфигурации • Создание окружений • Синхронизация тестовых окружений • Воспроизводимость
  6. 6. Chef http://chef.io
  7. 7. Шаблоны Chef • Плохо работают для часто меняющихся конфигов • Много лишней работы для большого числа параметров
  8. 8. Augeas http://augeas.net
  9. 9. Augeas $  cat  /etc/nginx/nginx.conf   user  www-­‐data;   worker_processes  4;   events  {                  multi_accept  on;   }   http  {     sendfile  on;     tcp_nopush  on;     tcp_nodelay  on;                  gzip  on;   }
  10. 10. Augeas $  augtool  print  /files/etc/nginx/nginx.conf   /files/etc/nginx/nginx.conf   /files/etc/nginx/nginx.conf/user  =  "www-­‐data"   /files/etc/nginx/nginx.conf/worker_processes  =  "4"   /files/etc/nginx/nginx.conf/events   /files/etc/nginx/nginx.conf/events/multi_accept  =  "on"   /files/etc/nginx/nginx.conf/http   /files/etc/nginx/nginx.conf/http/sendfile  =  "on"   /files/etc/nginx/nginx.conf/http/tcp_nopush  =  "on"   /files/etc/nginx/nginx.conf/http/tcp_nodelay  =  "on"   /files/etc/nginx/nginx.conf/http/gzip  =  "on"  
  11. 11. Augeas (ресурс Chef) augeas_template  "/etc/cinarra/cate/cate.conf"  do      template  "/etc/cinarra/cate/cate.conf.sample"      lens  "IniFile"      parameters(          "CATE/logging_lev"  =>  node.cate.log_level,          "CATE/cmgw_host"  =>  node.cate.cmgw_host,          "CATE/csync_host"  =>  node.cate.csync_host,          "CATE/csync_port"  =>  node.cate.csync_port      )      notifies  :run,  "execute[supervisorctl  restart  cate]"   end  
  12. 12. Augeas $  cat  /etc/cinarra/cate/cate.conf.sample   [CATE]   instance_id  =  1   logging_lev  =  6   cate_thread_n  =  2   cmgw_host  =  127.0.0.1   cmgw_num  =  2   csync_enabled  =  true   csync_host  =  127.0.0.1   csync_port  =  1234  
  13. 13. Augeas $  cat  /etc/cinarra/cate/cate.conf   [CATE]   instance_id  =  1   logging_lev  =  3                      #  cate.log_level  =  3   cate_thread_n  =  2   cmgw_host  =  10.0.0.2            #  cate.cmgw_host  =  10.0.0.2   cmgw_num  =  2   csync_enabled  =  true   csync_host  =  10.0.0.3          #  cate.csync_host  =  10.0.0.3   csync_port  =  1234                  #  cate.csync_port  =  nil  
  14. 14. Плюсы Augeas • Всеми конфигами управляем единообразно • Поддерживает почти все форматы конфигов • Строгий — встроенная валидация синтаксиса • Можно расширять
  15. 15. Минусы Augeas • Расширять сложно • Плохо работает с нестрогими форматами • Форматов обычно мало — теряет смысл
  16. 16. Vagrant http://vagrantup.com
  17. 17. Образ сервера • Jenkins ежедневно собирает AMI при помощи Packer • Публикует Vagrant box в нашем репозитории Vagrant
  18. 18. Vagrant box • Packer создает его, если указан постпроцессор • Кладем файл .box на локальный HTTP • Обновляем JSON с информацией о версиях
  19. 19. Vagrant box $  cat  ~/.vagrant.d/boxes/cinarra-­‐VAGRANTSLASH-­‐baseami-­‐ daily-­‐1.2/1.0.174/aws/Vagrantfile   Vagrant.configure("2")  do  |config|      config.vm.provider  "aws"  do  |aws|          aws.region_config  "eu-­‐west-­‐1",  ami:  "ami-­‐fb384f8c"      end   end  
  20. 20. vagrant box update Vagrant ищет JSON на http://vagrantcloud.com/box_name   ubuntu/precise64  ⟶     http://vagrantcloud.com/ubuntu/ precise64  
  21. 21. Vagrant box {  "name":  "orgname/baseami",      "description":  "Our  brand  new  vagrant  box",      "versions":  [          {  "version":  "1.0.1",              "providers":  [                  {  "name":  "aws",  "url":  "http:// www.example.com/boxes/orgname/baseami/1.0.1/ packer_amazon-­‐ebs_aws.box"  }]},          {  "version":  "1.0.2",              "providers":  [                  {  "name":  "aws",  "url":  "http:// www.example.com/boxes/orgname/baseami/1.0.2/ packer_amazon-­‐ebs_aws.box"  }]}   ]}
  22. 22. Vagrant box • Переопределяем VAGRANT_SERVER_URL • Сервер должен отдавать тип “application/json”
  23. 23. Разработчику #  Делается  один  раз  при  добавлении  box-­‐а   export        VAGRANT_SERVER_URL="http://www.example.com/boxes"   vagrant  box  add  orgname/baseami   #  Перед  работой  каждый  день   vagrant  box  update   vagrant  up   #  После  работы   vagrant  destroy
  24. 24. Jenkins http://jenkins-ci.org
  25. 25. Jenkins job
  26. 26. Проблемы • Параметры разбросаны по всей конфигурации • Кнопка “Advanced” • Сложно менять сразу несколько сборок • Работать в UI медленно
  27. 27. Jenkins job
  28. 28. Сборка без checkout
  29. 29. Сборка без checkout В остальном — обычная сборка
  30. 30. Jenkins job
  31. 31. Центральная сборка
  32. 32. Центральная сборка • Задает дополнительные параметры • Checkout всех git repo • Запускает сборки с нужными параметрами • Достает и публикует тесты и артефакты
  33. 33. Jenkins job
  34. 34. Вызов сборки
  35. 35. Другие варианты • Правка config.xml • Jenkins API • Workflow plugin
 https://wiki.jenkins-ci.org/display/JENKINS/Workflow+Plugin • Build Flow plugin
 https://wiki.jenkins-ci.org/display/JENKINS/Build+Flow+Plugin • Job DSL plugin
 https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin
  36. 36. Workflow plugin echo  "Building  in  ${env.BASEDIR}"   parallel  cnrMain:  {      echo  "Building  cnr-­‐main"      dir("cnr-­‐main")  {          gitCheckout(              "https://github.com/cinarra/cnr-­‐main.git",              "remotes/origin/${CNR_BRANCH}",              CNR_CREDENTIALS,  CNR_BUILD_TAG          )          sh  "make  clean  deb"          archive  includes:  "**/*.deb",  fingerprint:  true      }   },  cnrCWS:  {              echo  "Building  cnr-­‐cws"              .  .  .  .  .  .  .  .  .  .  .   }
  37. 37. Workflow plugin Плюсы: • Храним в Git • Меняем все сборки сразу • Легче читать и отслеживать логику
  38. 38. Workflow plugin Минусы: • Пока сыроват • Не совместим со многими плагинами
  39. 39. Общий план Github deb AMI Devs Tests Prod Preprod Staging Chef Vagrant
  40. 40. Спасибо! Мы ищем программистов Тимур Батыршин: • timur@cinarra.com • @erthad • http://slideshare.net/erthad

×