Как стать автором
Обновить
13
Карма
0
Рейтинг
Bogdan @1_k

DevOps

Обновление процесса CI/CD: год спустя

Системное администрирование *.NET *DevOps *

Это четвертая и заключительная часть цикла об обновлении CI/CD процессов. Кстати, вот оглавление:
Часть 1: что есть, почему оно не нравится, планирование, немного bash. Я бы назвал эту часть околотехнической.
Часть 2: teamcity.
Часть 3: octopus deploy.
Часть 4: внезапно вполне себе техническая. Что произошло за прошедший год.

Сейчас у нас есть рабочая система доставки обновлений, которая прошла испытание временем. О настройке этой системы можно прочесть в первых трёх частях, а сейчас предлагаю вкратце вспомнить что там было.

Осуществлялся переезд CI/CD системы с CruiseControl.NET + git deploy на Teamcity + octopus. Будем честны, CD там и не пахло. Об этом, возможно, будет отдельная статья, но не в этом цикле.
С момента выхода первой статьи цикла прошло чуть больше года, с момента начала работы системы в проде - примерно полтора. Процесс разработки во время внедрения новой системы практически не прерывался. Было два раза, когда делали code freeze: один раз в момент перехода с mercurial репозитория в git (чтобы не потерять коммиты во время конвертации), и второй раз во время перехода билда production окружения с ccnet на teamcity (просто так, на всякий случай). 
В результате мы получили систему которая способна наиболее оптимально (с минимальными время- и ресурсозатратами, а также с минимальными рисками) доставлять обновления во все существующие окружения.

С момента выхода 3 части статьи в конфигурации произошли некоторые изменения, о которых, наверное, стоит рассказать.

Читать далее
Всего голосов 5: ↑5 и ↓0 +5
Просмотры 3.5K
Комментарии 0

Обновление процесса CI/CD: octopus deploy

.NET *DevOps *
image Третья часть статьи об обновлении CI/CD процессов. 

На данном этапе у нас есть (по крайней мере должно быть) понимание того как будет работать CI, что мы имеем на входе, как из этого получить результат, и что нужно сделать чтобы выход билда стал полноценным модулем проекта и запустился в работу. А также установленный octopus (желательно LTS). В прошлой части рассматривался процесс настройки teamcity: всё что происходит с момента когда код попадает в репозиторий и до момента получения готового архива который можно распаковать, и в теории, он должен заработать.

Напоминаю оглавление:

Часть 1: что есть, почему оно не нравится, планирование, немного bash. Я бы назвал эту часть околотехнической.
Часть 2: teamcity.
Часть 3: octopus deploy.
Часть 4: за кадром. Неприятные моменты, планы на будущее, возможно FAQ. Скорее всего, тоже можно назвать околотехнической.
Читать дальше →
Всего голосов 3: ↑3 и ↓0 +3
Просмотры 3.8K
Комментарии 0

Обновление процесса CI/CD: teamcity

.NET *DevOps *
image
Это вторая статья из цикла об обновлении CI/CD процессов. До этого момента осуществлялась подготовка к настройке новых средств, а именно: планирование, ежедневные митинги, решение разногласий, в общем, все без чего не получится грамотно построить рабочий процесс. И вот, все вопросы улажены, мы уверены что можем продолжать разработку, и наш код не канет в чёрную дыру с началом лета. 

Напомню оглавление списка статей, а также краткие итоги предыдущей части.

Часть 1: что есть, почему оно не нравится, планирование, немного bash. Я бы назвал эту часть околотехнической.
Часть 2: teamcity.
Часть 3: octopus deploy.
Часть 4: за кадром. Неприятные моменты, планы на будущее, возможно FAQ. Скорее всего, тоже можно назвать околотехнической.
Читать дальше →
Всего голосов 6: ↑6 и ↓0 +6
Просмотры 4.6K
Комментарии 2

Обновление процесса CI/CD: подготовка и планирование

DevOps *
image

В 2020, наверняка, достаточно сложно найти проект в описании стека которого не было бы одного из следующих слов: IaC, микросервисы, kubernetes, docker, aws/azure/gcloud, блокчейн, ML, VR и так далее. И это здорово! Прогресс не стоит на месте. Мы растем, вместе с нами растут наши проекты, появляются более удобные и функциональные инструменты, которые решают современные проблемы.

Здравствуйте. Так я хотел начать эту статью. Но, потом я пересмотрел некоторые вещи, пообщался со своими коллегами, и понял что был бы не прав. Всё ещё существуют проекты которым уже по 15+ лет, у которых менеджеры и участники староверы, а соответственно у этих проектов древний стек технологий, который достаточно сложно поддерживать в существующем зоопарке. И по каким-либо причинам глобально обновить этот проект не получается (заказчик — старовер, нет аппрува, проект очень большой, и миграция затягивается, или всех все устраивает), и приходится его поддерживать. Еще более неприятно когда подобный проект все еще активно девелопится. Это как снежный ком. Заказчик и публика требуют фич, код требует доставки, сервера требуют внимания и заботы… А битбакет — так вообще, перестал поддерживать меркуриал. К рассмотрению предлагается как раз такой случай.
Читать дальше →
Всего голосов 5: ↑5 и ↓0 +5
Просмотры 3.3K
Комментарии 0

Как провайдеры заботятся о безопасности клиентов

Информационная безопасность *
Здравствуйте. Казалось бы, в современном мире есть довольно очевидные (даже для среднестатистического человека не связанного напрямую с IT) понятия. Например, что хранить пароли плейнтекстом в txt на рабочем столе — это плохо. Но, хостинг ukraine, к сожалению, понял это только в январе 2020. Ссылку не оставляю, дабы не нарушать правила, но гуглится быстро. А что же с другими провайдерами? Например, с интернет-провайдерами. Я решил провести небольшой эксперимент, и поделиться им с вами. Скажу сразу: у меня не было никакого злого умысла, как и не было цели навредить кому-либо. Зато есть цель донести до людей что стоит более ответственно относиться к пользовательским данным и личным кабинетам, в особенности, если в них есть возможность беспрепятственно менять настройки. Возможно, если эту ситуацию придать огласке что-то изменится. А может и нет. Кто знает… Я все же попробую.
Читать дальше →
Всего голосов 25: ↑22 и ↓3 +19
Просмотры 14K
Комментарии 26

На пути к автоматизации выпуска SSL

Администрирование доменных имен *Системное администрирование *IT-инфраструктура *DevOps *
Из песочницы
Tutorial

Достаточно часто нам приходится работать с SSL сертификатами. Давайте вспомним процесс создания и установки сертификата (в общем случае для большинства).


  • Найти провайдера (сайт на котором мы можем купить SSL).
  • Сгенерировать CSR.
  • Отправить его провайдеру.
  • Подтвердить владение доменом.
  • Получить сертификат.
  • Преобразовать сертификат в нужную форму (опционально). Например, из pem в PKCS #12.
  • Установить сертификат на веб сервер.

Относительно быстро, не сложно и понятно. Этот вариант вполне годится, если у нас есть максимум десяток проектов. А если их больше, и у них минимум по три окружения? Классический dev — staging — production. В этом случае стоит задуматься об автоматизации этого процесса. Предлагаю, немного углубиться в проблему и найти решение которое в дальнейшем минимизирует временные затраты на создание и обслуживание сертификатов. В статье будет присутствовать анализ проблемы и небольшое руководство к повторению.


Заранее оговорюсь: основная специализация нашей компании — .net, а соответственно IIS и прочие виндовые вытекающие. Поэтому, ACME клиент и все действия для него тоже будут описаны с точки зрения использования windows.


Для кого это актуально и некоторые исходные данные

На конкретном примере
Всего голосов 6: ↑5 и ↓1 +4
Просмотры 7.7K
Комментарии 8

Информация

В рейтинге
Не участвует
Откуда
Харьков, Харьковская обл., Украина
Зарегистрирован
Активность