В первом уроке мы разобрались как развернуть проект в локальной среде, имеем представление о построении структуры. Наступила пора поговорить о втором не маловажном шаге - это серверная реализация приложения с Ci\CD Deploy, а если говорить правильно, публикация в сети с функциями автоматического Deploy (развертывания).
Doсker и зачем он разработчику.
Пока мы учимся, можно все делать локально, поэтому сегодня познакомимся и развернем наш проект локально в Docker контейнере, отличий от серверных развертываний почти нет. Что такое Docker и как он работает, я рассказывать в этой статье не буду, но если есть большое желание, жду подписку, комментарии и я смогу подготовить материал. Пока же мы приступаем к запуску.
1. Установка Docker, делается несколькими командами и не нужно изобретать велосипед. Вот ссылка на документацию устанавливаем и работаем.
2. Когда все установлено, необходимо иметь в запасе команду которая позволит содержать Docker в чистоте. Это команда
docker system prune
С ее помощью, вы очищаете (удаляете) все не используемые или не связанные с контейнерами образы, остановленные и не нужные контейнеры удаляются, тома и сети контейнеров так же подлежат удалению.
Другой мусор чистить надо иначе, но об этом в другой раз и чуть подробней, чем просто о мусоре. При активной работе и отладке иногда контейнеры рабочие и временные очень быстро забивают диск и может случится неприятный момент.
Совет
После каждого рабочего дня я чищу свою систему, не только удаляя ненужные контейнеры, но и прохожу скриптом по временным файлам и кукам если это был Frontend (обязательно поделюсь и расскажу как содержать в чистоте свое рабочее место). Это позволяет на следующий день не нарваться на какой то странный баг с версткой потому где то кэш браузера забился, а так же не получить зависший комп если места на диске нет при пробуждении рабочего коня с утра. Это конечно дело каждого, но опыт показывает хороший результат, а из плюсов у вас каждый день с чистого листа и порядок на рабочей машине.
Немного не по теме урока, но стоит помнить что если у вас SSD диск не важно какого он производителя (особенно бытовые), свободное место на диске всегда должны быть не менее 20% от общего объема. Если места меньше, диск начинает сам себя пережевывать убивая себя же.
В профессиональных дисках это требование чуть менее важно, но я все равно это всегда выдерживаю. Если вы в всерьез занялись программированием, не пожалейте 7-9 тыс рублей на хороший диск. Сейчас это не роскошь и вам будет достаточно для начала Samsung EVO любой по объему. У меня на 512Gb мне для работы вполне хватает (да все большое лежит отдельно на внешнем носителе и у меня собран NAS).
Что нам позволит делать Docker?
Во первых Docker - это серверные решения, а рано или поздно нам придется свой проект выложить сеть и нам нужно будет это знать.
Во вторых если программист знает Docker - это уже сегодня просто стандарт, то его цена на рынке уже на 10% дороже, чем просто программиста.
В третьих, у вас будет возможность поработать с большой структурой больших компаний, когда есть DEV среда, TEST и PROD. Именно знание такой архитектуры делает вас на рынке труда дороже, так как вас не нужно будет учить, как работать в команде.
Помните! Чем больше у вас знаний тем вы дороже на рынке труда и ваше резюме выглядит привлекательней.
Управление контейнерами Docker.
Для управления контейнерами есть несколько путей.
- Стандартная консоль (командная строка) cmd для Windows или terminal для linux & nix системах.
- Базовая консоль для Descktop от Docker (GUI интерфейс). Она есть под все платформы, достаточно удобна для работы с локальными контейнерами.
- Web платформы на базе контейнеров на примере Porteiner. Это среды с более широкими возможностями. Они позволяют управлять контейнерами не только локально но и на удаленных нодах. Я использую именно porteiner так как для меня необходимо управление и удаленными серверами.
Из личного. Для того, чтобы освоить Docker всем рекомендую начать с консольных команд. Самые простые команды - это запуск контейнера из готового образа, остановка, а так же подключение к самому контейнеру в bash среду, для проверки работы своих приложений внутри контейнера. Максимальный профит от консольных команд вы получите во время разработки. Не выходя из среды разработки вы будете спокойно подключаться к контейнерам и работать в их среде. Мы будем обязательно это рассматривать в уроках и есть желание написать на эту тему отдельную статью.
Когда мы легко управляем, тем что создаем и выдаем нашим заказчикам, то и работа становится в радость. Программисты которые имеют широкий кругозор, в разы больше востребованы, чем те кто уперлись в одну нишу и говорят, что это круто.
Когда и как публиковать свои проекты.
Вообще этот вопрос стоит разделить на два основных направления.
Первое - вы учитесь и делаете различные PET проекты. Их стоит публиковать в открытом виде на GIT платформах и собирать в свое портфолио. Только когда вы это делаете, думайте о том, что нужно все сопровождать описанием. Что вы сделали, зачем и как это можно использовать и если кто то захочет улучшить вашу разработку, что ему делать - оставляйте контакты.
Второе - коммерческая разработка. Тут включаем голову и никаких публичных репозиториев. NDA в вашей голове - это продукт который стоит для кого то больших денег, для Вас лично сил за которые вам платят. Сливая это куда то типа я разработал, то это мое - нет. За такое могут быстро показать клетчатое небо, прогулка раз в день на часок и баланду без соли. Поэтому внимательно относитесь к своим публикациям.
Лирику закончили, переходим к задачам публикации - CI\CD Deploy
Шаг №1 на пути к публикации
Перед началом публикации необходимо подготовить саму конфигурацию проекта.
Файлы конфигурации мы уже готовили в первом уроке, ссылка на урок будет в конце статьи и поэтому теперь мы шире и подробнее рассмотрим сам процесс, а так же рассмотрим серверную часть.
Первое что нам будет необходимо - это GIT сервер. Формально это может быть облачная платформа в бесплатном варианте. Рекомендую на текущий момент обратить внимание на gitverse.ru. (НЕ РЕКЛАМА, но если ребята захотят то могу сделать качественный обзор платформы)
- Мои материалы бесплатно выложены на gitverse.ru, ссылка в конце статьи
- Бесплатная VDS реальный опыт работы с облаками, как всегда ссылка в конце статьи и персональные плюшки от меня у лучших хостеров.
Можно конечно играться и на локальных данных, поднимая все у себя, но это будет только для себя, без должного опыта работы с облаками. Когда обзавелись GIT платформой и сервером, давайте обеспечим себя необходимой информацией для работы с нашим проектом.
1. Создайте первый проект и войдите в него.
На примере gitverse.ru, нам в репозиторий надо включить функцию CI\CD, для этого идем в наш репозиторий, пробегаем скролом основную информацию и видим переключатель CD\CD. Первое, что бы ребятам хотелось сказать - вынесите в отдельный пункт данную настройку или включите по умолчанию. Когда включили переключатель, не забудьте нажать кнопочку "Обновить", а то ничего не сохранится. Опять же почему " "обновить" - загадка.
Теперь движемся далее, поднимем глаза на верхнее в меню проекта и увидим пунктик CD\CD с припиской beta
То, что beta не обращайте внимания, в целом все работает, просто маловато функционала. Я попытался запустить сложный проект на данной платформе, без костылей не обошлось, но оно работает и вполне себе стабильно. Если вы боитесь за свои данные имейте backUP ну и переезжайте в РФ, так все же спокойней.
У ребят есть неплохая документация по CI\CD расположенная по ссылке https://gitverse.ru/docs/knowledge-base/actions/, по сути там описано все что надо сделать, но так как мы учимся я расскажу подробно, что за чем делаем.
2. Сделаем необходимые конфигурационные файлы
Сделайте клонирование проекта к себе на рабочую станцию, но можно и web все править, кому как удобно. Нам предлагается сделать файл yaml который мы делали уже и понимаем зачем он нужен. Если забыли, то это самый главный файл описывающий что делать CD\CD при запуске (описание конфигурации).
Итак желаем директории по примеру инструкции и закидываем туда нашу конфигурацию (пример из инструкции: .gitverse/workflows/, отступать не будем).
Незабываем все это запушить
И вот на этом месте у нас сразу же просит ввести комментарий - обязательно вводим. Любой уважающий себя программист пишем комментарий, зачем сделан пуш, а в больших командах еще и привяска к задачам идет, о чем позже расскажу.
Ну вводим, логин с паролем от GIT среды. Выскажите и так каждый раз?, нет можно все упростить перейдя на ssh ключи. Для этого идем к пункту три.
Вот такой результат мы получили
В заголовке проекта видно что я сделал push, написал комментарий, а в проекту появилась наша с вами структура папок и файл конфигурации.
Перейдем в раздел CI\CD, увидим что у нас есть потоки, есть наименование нашего push т.е. если мы у нас уже был сервер, то эти данные полетели бы на него.
Если вы обратили внимание, рядом с наименование коммита есть значок часов. Это значит среда что то ждет.
3. Настройка сервера.
Настройку будем рассматривать на примере бесплатной VDS от cloud.ru. Захотелось посмотреть на их решение (это не реклама) никаких ссылок на с партнерским кодиком не будет.
На этапе создания бесплатной машины, нам предлагают создать ключ доступа или использовать пароль. Я пока предлагаю использовать только пароль, о ключах расскажу в конце.
Ну вот и сама машинка. В статусе создается. Ждем когда она будет готова к работе. Для этого смотрим в колонку "Статус". Создание машины у меня заняло около 4-х минут. Тут без претензий ибо бесплатно!
В инструкциях cloud.ru все есть, если нужно рассмотреть отдельно пишите в коментах, чем помочь или записывайтесь на личную консультацию. Идем дальше и как обещал теперь о ключах.
Шаг №2 на пути к публикации SSH ключи.
Как и в любой системе мы должны помнить о защите информации, надежных паролях, но программисты - это люди консоли и для них придумали SSH ключи.
SSH ключи очень удобны для администраторов, а программистам облегчают жизнь не заставляя помнить пароли к dev серверам, test средам и прочим рабочим элементам.
Когда создан SSH ключ, ваша среда разработки и в целом рабочая машина имеет полный доступ к GIT ветке, серверу и это экономит много времени.
Шаг №3 настройка ранеров или служебной учетной записи на сервере для работы CI\CD
- Из шага №1 мы уже имеем созданый yaml файл demo.yaml рабочего процесса (workflow) в каталоге .gitverse/workflows/ репозитория.
- Далее по инструкции нам нужно скачать бинарный файл. Он позволит установить необходимый софт на сервере. В инструкции gitverse все отлично описано повторяться не буду.
- Выполняем все по шагам всю инструкцию до конца и по факту у нас все будет работать. Честно я не ожидал, что используя копипаст из инструкции все сработает, но ошибся. Ребята постарались и все описали верно.
Подводим итоги
Пробежав быстро по теме CI\CD мы сейчас понимаем, что не так страшен черт как его малюют. Процедуры уже давно отлаженые и если ваш продукт не имеет много специфических компонентов требующих описания процесса установки в yaml, то деплой настраивается очень быстро.
Важно уметь это делать на базовом уровне, не до фанатизма. Программисты обладающие базовым навыком работы с CI экономят очень много времени на проектах. Получают больше баллов на собеседовании и в целом более автономны в свой работе.
Ссылки к статье.
Ссылка на урок №1 https://dzen.ru/a/Zb6XO0ipqnvOkkec
Ссылка на репозитарий с уроком https://gitverse.ru/VMCOM/CI_CD_lesson