Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

569 visualizaciones

Publicado el

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

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

Publicado en: Tecnología
  • Inicia sesión para ver los comentarios

Масштабируемый 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/

×