Масштабируемый DevOps

448 views

Published on

Александ Колесень «Масштабируемый DevOps»

Доклад на июльской линуксовке MLUG 2013

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
448
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
8
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Масштабируемый DevOps

  1. 1. МАСШТАБИРУЕМЫЙ DEVOPS АЛЕКСАНДР КОЛЕСЕНЬ
  2. 2. О СЕБЕ • shop.by - System Engineer - FreeBSD, Linux, Apache, nginx, C, C++, perl, MySQL • Wargaming.net - Web DevOps - Linux, Apache, nginx, AMQP/RabbitMQ, Python, Django, MySQL, memcached, lxc, puppet, fabric • SiliconMint, Iron.io - DevOps, System Engineer - Linux, Python, Ruby, RoR, Go, MongoDB, MySQL, Redis, memcached, AMQP/RabbitMQ, AWS, lxc, chef, fabric, Capistrano
  3. 3. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
  4. 4. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ • FreeBSD vs. Ubuntu vs. CentOS vs. Debian vs. ...
  5. 5. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ • FreeBSD vs. Ubuntu vs. CentOS vs. Debian vs. ... • apache vs. uwsgi vs. tornado vs. ...
  6. 6. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ • FreeBSD vs. Ubuntu vs. CentOS vs. Debian vs. ... • apache vs. uwsgi vs. tornado vs. ... • MySQL vs. PgSQL vs. CouchBase vs. MongoDB vs. ...
  7. 7. ПЕРВЫЕ ШАГИ # make # cp libproject.so /var/www/ или $ scp -r site host:/tmp/ # cp -R /tmp/site /var/www/ # apachectl restart ... # killall -9 httpd # apachectl start
  8. 8. VCS UP?! # apachectl stop # svn up / git pull # apachectl start
  9. 9. VCS UP?! # apachectl stop # svn up / git pull # apachectl start # svn / git log ... "Last fix on #456" "Still fixing #456" "One more commit on #456" "Fixed bug #456"
  10. 10. ФАЗЫ ДЕПЛОЙМЕНТА • подготовка окружения - основная работа выполняется единоразово - инкрементальные обновления (конфиги, софт и т.п.)
  11. 11. ФАЗЫ ДЕПЛОЙМЕНТА • подготовка окружения - основная работа выполняется единоразово - инкрементальные обновления (конфиги, софт и т.п.) • деплоймент - полностью каждый раз при обновлении
  12. 12. ОКРУЖЕНИЕ
  13. 13. ОКРУЖЕНИЕ • смотрим на продакшн
  14. 14. ОКРУЖЕНИЕ • смотрим на продакшн • руками :( ставим такие же пакеты
  15. 15. ОКРУЖЕНИЕ • смотрим на продакшн • руками :( ставим такие же пакеты • пакета нет - ./configure && make && make install :(
  16. 16. ОКРУЖЕНИЕ • смотрим на продакшн • руками :( ставим такие же пакеты • пакета нет - ./configure && make && make install :( • (может быть) записываем действия в .sh-скрипт
  17. 17. ОКРУЖЕНИЕ • смотрим на продакшн • руками :( ставим такие же пакеты • пакета нет - ./configure && make && make install :( • (может быть) записываем действия в .sh-скрипт Итог: • Ubuntu, CentOS etc. превращается в “Slackware”
  18. 18. ОКРУЖЕНИЕ • смотрим на продакшн • руками :( ставим такие же пакеты • пакета нет - ./configure && make && make install :( • (может быть) записываем действия в .sh-скрипт Итог: • Ubuntu, CentOS etc. превращается в “Slackware” • много чего забывается
  19. 19. ОКРУЖЕНИЕ • смотрим на продакшн • руками :( ставим такие же пакеты • пакета нет - ./configure && make && make install :( • (может быть) записываем действия в .sh-скрипт Итог: • Ubuntu, CentOS etc. превращается в “Slackware” • много чего забывается • конфигурация скорей всего будет различаться
  20. 20. ОКРУЖЕНИЕ: АВТОМАТИЗАЦИЯ Декларативная конфигурация Важно, ЧТО будет в итоге, а не КАК это будет выполнено
  21. 21. ОКРУЖЕНИЕ: АВТОМАТИЗАЦИЯ Chef, puppet cron "mycrontab" do minute "0" hour "0,12" user "www-rest" command "cd /home/#{app_config[:user]}/app/src/worker && . ../../bin/activate && python db_validator.py ../../conf/app.json" mailto "#{app_config[:email]}" end
  22. 22. ОКРУЖЕНИЕ: АВТОМАТИЗАЦИЯ Запуск $ knife ssh ’name:api.myservice.com’ ’sudo chef-client’ Не важно, как, но запись оказывается в crontab: $ crontab -l # Chef Name: mycrontab MAILTO=alexander.kolesen@gmail.com 0 0,12 * * * cd /home/www-rest/app/src/worker && . ../../bin/activate && python db_validator.py ../../conf/app.json
  23. 23. ДЕПЛОЙМЕНТ: АВТОМАТИЗАЦИЯ Императивный процесс 1. закачиваем и распаковываем исходники 2. закрываем доступ к серверу 3. останавливаем сервер 4. обновляем исходный код 5. накатываем миграции 6. перезапускам фоновые рабочие задачи 7. запускаем сервер 8. тестируем 9. открываем доступ к серверу
  24. 24. ДЕПЛОЙМЕНТ: АВТОМАТИЗАЦИЯ Fabric, capistrano def upload(): rsync_project("app/src", "rest worker install tools", exclude = ["*.pyc"], delete=True) def restart(): run("nohup %s/app/src/tools/worerks.sh restart -n8" % homedir()) run("sudo /etc/init.d/apache2 graceful") def deploy(): upload() restart()
  25. 25. ДЕПЛОЙМЕНТ: АВТОМАТИЗАЦИЯ Запуск $ fab deploy -H api.myservice.com -u www-rest Результат 1. rsync проекта на api.myservice.com 2. перезапуск сервисов
  26. 26. БЕСШОВНОЕ ОБНОВЛЕНИЕ Это хорошо!
  27. 27. БЕСШОВНОЕ ОБНОВЛЕНИЕ Это хорошо! • если обновляются только css/js - нет смысла выключать
  28. 28. БЕСШОВНОЕ ОБНОВЛЕНИЕ Это хорошо! • если обновляются только css/js - нет смысла выключать • если обновляется код - отключаем бэкенды “по очереди”
  29. 29. БЕСШОВНОЕ ОБНОВЛЕНИЕ Это хорошо! • если обновляются только css/js - нет смысла выключать • если обновляется код - отключаем бэкенды “по очереди” • если обновляется база (миграции) - ReadOnly-режим
  30. 30. БЕСШОВНОЕ ОБНОВЛЕНИЕ Это хорошо! • если обновляются только css/js - нет смысла выключать • если обновляется код - отключаем бэкенды “по очереди” • если обновляется база (миграции) - ReadOnly-режим • иначе показываем “картинку”: “Мы обновляемся”
  31. 31. БЕСШОВНОЕ ОБНОВЛЕНИЕ Nginx, maintenance mode map $remote_addr $under_construction { default under_construction.jpg; 193.232.92.23 .; } location / { try_files $under_construction @backend; } location @backend { proxy_pass http://<upstream>; }
  32. 32. СТЕЙДЖИНГ Пре-продакшн
  33. 33. СТЕЙДЖИНГ Пре-продакшн • как можно более близкий по конфигурации к продакшну
  34. 34. СТЕЙДЖИНГ Пре-продакшн • как можно более близкий по конфигурации к продакшну • но без фанатизма
  35. 35. СТЕЙДЖИНГ Пре-продакшн • как можно более близкий по конфигурации к продакшну • но без фанатизма • вечный дефицит железа для стейджингов
  36. 36. СТЕЙДЖИНГ Пре-продакшн • как можно более близкий по конфигурации к продакшну • но без фанатизма • вечный дефицит железа для стейджингов • поэтому виртуальные окружения: lxc, kvm, xen - OK
  37. 37. СТЕЙДЖИНГ Пре-продакшн • как можно более близкий по конфигурации к продакшну • но без фанатизма • вечный дефицит железа для стейджингов • поэтому виртуальные окружения: lxc, kvm, xen - OK • если мы на AWS/EC2, Rackspace - не нужно железа, OK
  38. 38. ТЮРЬМА
  39. 39. ТЮРЬМА • приложение работает от “restricted” пользователя
  40. 40. ТЮРЬМА • приложение работает от “restricted” пользователя • максимум - пару sudo на graceful-перезапуск Web-сервера
  41. 41. ТЮРЬМА • приложение работает от “restricted” пользователя • максимум - пару sudo на graceful-перезапуск Web-сервера • приложение не навредит системе
  42. 42. ТЮРЬМА • приложение работает от “restricted” пользователя • максимум - пару sudo на graceful-перезапуск Web-сервера • приложение не навредит системе • ни другим приложениям
  43. 43. ТЮРЬМА • приложение работает от “restricted” пользователя • максимум - пару sudo на graceful-перезапуск Web-сервера • приложение не навредит системе • ни другим приложениям • пользователь (разработчик) тоже
  44. 44. ТЮРЬМА • приложение работает от “restricted” пользователя • максимум - пару sudo на graceful-перезапуск Web-сервера • приложение не навредит системе • ни другим приложениям • пользователь (разработчик) тоже • можно разрешать деплоить самому разработчику
  45. 45. ТЮРЬМА • приложение работает от “restricted” пользователя • максимум - пару sudo на graceful-перезапуск Web-сервера • приложение не навредит системе • ни другим приложениям • пользователь (разработчик) тоже • можно разрешать деплоить самому разработчику • root-только для диагностики, в крайних случаях
  46. 46. ТЮРЬМА • приложение работает от “restricted” пользователя • максимум - пару sudo на graceful-перезапуск Web-сервера • приложение не навредит системе • ни другим приложениям • пользователь (разработчик) тоже • можно разрешать деплоить самому разработчику • root-только для диагностики, в крайних случаях • все остальное - chef, puppet
  47. 47. SSH-КЛЮЧИ
  48. 48. SSH-КЛЮЧИ • private & public-части
  49. 49. SSH-КЛЮЧИ • private & public-части • private - ТОЛЬКО у вас
  50. 50. SSH-КЛЮЧИ • private & public-части • private - ТОЛЬКО у вас • НЕЛЬЗЯ раздавать по скайпу, почте, на флешке
  51. 51. SSH-КЛЮЧИ • private & public-части • private - ТОЛЬКО у вас • НЕЛЬЗЯ раздавать по скайпу, почте, на флешке • public - на сервере, в authorized_keys
  52. 52. SSH-КЛЮЧИ • private & public-части • private - ТОЛЬКО у вас • НЕЛЬЗЯ раздавать по скайпу, почте, на флешке • public - на сервере, в authorized_keys • если кому-то нужен доступ - добавляем в authorized_keys
  53. 53. SSH-КЛЮЧИ • private & public-части • private - ТОЛЬКО у вас • НЕЛЬЗЯ раздавать по скайпу, почте, на флешке • public - на сервере, в authorized_keys • если кому-то нужен доступ - добавляем в authorized_keys • с помощью chef/puppet
  54. 54. CONTINIOUS INTEGRATION Как web frontend к скриптам деплоймента
  55. 55. CONTINIOUS INTEGRATION Как web frontend к скриптам деплоймента • деплоймент “по кнопке”
  56. 56. CONTINIOUS INTEGRATION Как web frontend к скриптам деплоймента • деплоймент “по кнопке” • деплоймент “по коммиту”
  57. 57. CONTINIOUS INTEGRATION Как web frontend к скриптам деплоймента • деплоймент “по кнопке” • деплоймент “по коммиту” • деплоймент “по крону”, раз в час/два/день
  58. 58. ИТОГО • использовать проверенный софт • автоматизировать подготовку окружения • автоматизировать деплоймент приложения • сделать обновление максимально “беcшовным” • деплоить на стейджингах, потом - в продакшне • ограничивать себя в правах • дать пользователям кнопку “сделать хорошо”
  59. 59. СПАСИБО ЗА ВНИМАНИЕ. ВОПРОСЫ Александр Колесень mailto:alexander.kolesen@gmail.com https://twitter.com/imm0use https://plus.google.com/107935551373006842102/

×