Как опубликовать лендинг (Landing Page) Деплой и секреты Devops. OpenOffice

В прошлых роликах Настя и Даня рассказали о том как сделать дизайн и верстку а сегодня я расскажу о том как сделать так, чтобы лэндинг попал в интернет, т.е. о деплое и devops. Сначала расскажу о нашей инфраструктуре, а потом покажу как у нас происходит деплой приложений. Итак инфраструктура: Для того, чтобы разместить лэндинг в интернет нужен сервер. А чтобы обеспечить отказоустойчивость на случай выхода из строя сервера - необходимо несколько серверов. Мы у себя организовали отказоустойчивый кластер из нескольких серверов. Нашим кластером управляет kubernetes. Kubernetes это фреймворк с открытым исходным кодом, предназначенный для оркестрации контейнеров. Он позволяет легко запускать, масштабировать и балансировать контейнеризированные приложения. Как вы поняли сами лэндинги мы пулбикоем через docker контейнеры. Docker дает возможность создавать изолированные окружения, что позволяет нам запускать лэндинг не зависимо от окружения самого сервера. Мы постоянно прогрессируем и развиваемся, улучшаем технологии и средства разработки. С начала запуска первого лэндинга, до сегодняшнего дня мы улучшили очень многие аспекты и благодаря контейнерезации docker мы можем запускать все наши приложения не зависимо друг от друга на одних и тех же серверах. Связка kubernetes и docker позволяют нам создать отказоустойчивый кластер. В случае выхода из строя одного из серверов - все контейнеры с приложениями распределяются среди работающих. Это занимает меньше минуты. Так же мы можем выделять особо важные приложения и запускать их сразу на всех машинах кластера, что вообще исключает простой этого приложения в случае поломки сервера. И так, получив запрос от браузера клиента для открытия лэндинга - этот запрос принимает kubernetes, находит и отдает нужный контейнер из кластера. в роли load балансера, принимающим запросы у нас используется ingress контроллер. Именно он принимая на вход адрес сопоставляет его с запущенным контейнером (или несколькими контейнерами) и отдает его. Сам docker контейнер у нас устроен следующим образом: В зависимости от версии и необходимого функционала внутри для отдачи запросов запущен nginx или nodejs. Так же там находится сам скомпилированный код лэндинга, который мы верстали в одном из прошлых видео. Сейчас я расскажу о том как код попадает в контейнер и каким образом происходит его доставка в кластер ( как бы начался деплой ). Для хранения кода, его компиляции и доставки мы используем gitlab. Это свободный аналог github. Одной из особенностей за которые нам понравился gitlab стала его встроенная система continuous integration или CI. К слову мы используем подход инфраструктура как код. Это означает, что все настройки наших серверов и окружений находятся в репозиториях рядом с кодом самого приложения. Это позволяет нам иметь некий коммит в гите, после которого и код и инфраструктура точно собирается и работает как надо. Такие коммиты мы можем пометить тегами версий и быть уверенными, что эта версия всегда будет работать. Т.е. исключаются ситуации когда к примеру программист использует старые версии библиотек, а админ обновил их на новые и код перестает работать. В корне проекта лежит специальный скрпипт на языке разметки yaml: . В этом скрипте указываются этапы непрерывной интеграции. В нашем случае создание контейнера, деплой на тестовое окружение, деплой на продакшен, очистка. На основании этого файла gitlab организует процесс Continuous integration. Пойдем по порядку. Вся цепочка интеграции у нас происходит с помощью утилиты dapp. Эта утилита позволяет создавать docker контейнеры и является связующим звеном между кодом, инфраструктурой, описанной кодом ( в нашем случае это Chef ) и Kubernetes ( через пакетный менеджер для kubernetes - helm ). Как видим в первой фазе под названием build происходит создание контейнера на основе dappfile. Это аналог dockerfile, только под утилиту dapp. В этом файле так же описываются стадии создания контейнера, но он немного более “прокачанный”. Тут можно указывать внешний контекст для монтирования каталогов, которые используются во время сборок, но исключаемых из конечного образа. Можно использовать сторонние инструмены на этапе сборки, но так же не включать их в финальный образ, поддерживается кэш, поддерживается chef, позволяющий настраивать системы в Docker-образах. Все это как раз и позволяет значительно ускорить создание docker-образов. Звоните и заказывайте прямо сейчас: 8(800)500-1444 Бесплатный звонок по России ---------------------------------------- Подписывайтесь на наш канал и ставьте лайки : ) ---------------------------------------- Официальный сайт ----------------------------------------