OS: "Linux Debian/Ubuntu", "MS Windows 7/8/10/2008/2012/2016/2019".
Apps: "Cygwin", "OpenSSH", "Cmd/PowerShell", "Java 11", "Jenkins".

Задача: подключение агентов исполнения "Jenkins Slaves" в операционных системах "MS Windows" в среде "Java 11+", через SSH-соединение.

Немного о том, отчего возникла надобность в написании этой инструкции. Ранее, когда "Jenkins" запускался в среде "Java 8", на операционных системах "Microsoft Windows" посредством технологии "WebStart (JNLP)" можно было быстро и непринуждённо запускать агенты исполнения "Jenkins Slaves" прямо из браузера, в пару щелчков мыши. Но из "Java 11" поддержка устаревшей "WebStart" была вырезана и теперь запуск агентов на windows-системах приходится осуществлять также, как и для linux-систем - через сеансы SSH-подключений. Это влечёт за собой необходимость устанавливать на windows-системах службы "OpenSSH", помимо "Java", в любом случае необходимой.

Последовательность дальнейших действий такова:

   [ уже посетило: 3700 ]   [ просмотреть в полном объеме ]

OS: "Linux Debian 9/10", "Linux Ubuntu Server 16/18/20 LTS".
Apps: "Jenkins", "Java 8/11", "Nginx", "Let`s Encrypt", "Docker", "Docker Compose".

Задача: развернуть несколько инстансов "Jenkins" в среде контейнеризации "Docker" с целью изоляции процедур CI/CD раздельно работающих команд разработки.

Прежде всего надо бы рассказать, отчего такая задача - изоляция команд разработки путём запуска для них отдельных CI/CD-серверов - возникла. Дело в том, что у "Jenkins", который вырос из маленького подручного инструмента, вообще нет механизмов ограничения доступа к его же внутренностям - практически любой полноценный пользователь web-интерфейса может получить доступ к другим проектам на этом сервере, даже несмотря на то, явно ему туда ходить не разрешено или даже запрещено плагинами. Об этом я ранее уже рассказывал в предыдущей инструкции по запуску одного экземпляра "Jenkins". Ввиду невозможности изолировать проектные группы в рамках одного инстанса "Jenkins" приходится запускать по экземпляру "Jenkins" для каждой проектной группы по отдельности. Это несложно, как станет понятно далее.

Перед тем, как перейти к дальнейшим инсталляционным работам важно учесть следующий нюанс. Работа "Jenkins" поддерживается только в среде исполнения "Java 8" и "Java 11 (LTS)" (причём не основной ветви "Sun/Oracle Java", а не бесплатном "OpenJDK JVM"). "Jenkins" запустится и будет работать внешне одинаково, с точки зрения конечного пользователя, на любой из этих двух версий "Java". Но из "Java 11" вырезана поддержка устаревшей технологии "WebStart (JNLP)" посредством которой быстро и непринуждённо подключаются к серверу "Jenkins" агенты исполнения "Slaves" в среде операционных систем "Microsoft Windows" - прямо из браузера, в пару щелчков мыши. Если "Jenkins" запустить в среде "Java 11", то подключение агентов на windows-системах придётся осуществлять так же, как и для linux-систем - через сеансы SSH-подключений. Это влечёт за собой необходимость устанавливать на windows-системах службы "OpenSSH". Таким образом, мы стоим перед выбором: работать на старье, но проще подключать агентов исполнения, или идти в ногу с прогрессом, усложняя себе задачу предварительной подготовки к CI/CD-процедурам на операционных системах "Microsoft Windows". Здесь рассматривается инсталляция "Jenkins" в среде "Java 11".

Добавлю ещё немного рассуждений об инсталяции. "Jenkins" представляет собой монолитное приложение, запускаемое как java-сервлет в любом современном сервере приложений, вроде "Jetty", "Apache Tomcat", "GlassFish" или "WildFly". Ещё три года назад я бы собрал из распространяемого командой разработчиков "Jenkins" WAR-файла и "Tomcat" свой docker-образ. Однако сейчас вся эа работу уже проделана людьми гораздо опытнее меня и на "Docker Hub" нас ждёт всегда актуальные сборки "Jenkins in Docker", за качество сборки которых волноваться не приходится, судя по простоте и аккуратности "Dockerfile". Процесс развёртывания и конфигурирования разработчиками "Jenkins" хорошо расписан (здесь и здесь, с вариациями), так что просто сделаем это.

Последовательность дальнейших действий такова:

   [ уже посетило: 5818 ]   [ просмотреть в полном объеме ]

Некоторое время у меня не было определённости, каким инструментарием управлять процессами CI/CD сборок сразу для "Linux", "MacOS", "Microsoft Windows", а также, потенциально, для мобильных платформ. Была мысль воспользоваться для управления сборками сервером "GitLab", но позже стало понятно, что эта идея хороша лишь для небольшой команды с одним-двумя продуктами.

Прежде всего, в случае использования "GitLab", для управления удалёнными стендами сборки (CI) и серверами развёртывания (CD) понадобится постоянное прямое соединение с центром управления, что делает схему небезопасной в том смысле, что к хранилищу исходного кода придётся организовать доступ отовсюду - надо оно на самом деле, или нет. Таким образом, в корпоративной среде сервис CI/CD должен быть реализован в виде отдельного сервера, чтобы минимизировать прямые бесконтрольные соединения с хранилищем репозиториев кода.

В процессе тестирования разных вариантов использования выявлено, что "GitLab" откровенно заточен под программные продукты на "Linux" и "MacOS", настолько, что для агента исполнения "GitLab Runner" в "Microsoft Windows" даже отображение символов национальных кодировок (русской, например) журнала событий простыми методами невозможно настроить - для "Linux" и "MacOS" без проблем, а вот транскодированием комбинаций "cp866", "cp1251" и "utf8" разработчики "GitLab" фактически попросту отказались заниматься.

   [ уже посетило: 5639 ]   [ просмотреть в полном объеме ]

OS: "Linux Debian 9/10", "Linux Ubuntu Server 18/20 LTS".
Apps: "Passwork v4.0.10/4.1.7", "Nginx", PHP, "Phalcon 3.4", "MongoDB", "mSMTP", "Docker", "Docker Compose", LDAP, "IPtables".

Задача: развернуть в среде исполнения "Docker" написанное на "PHP + Phalcon" web-приложение "Passwork", предназначенное для хранения и управления паролями в корпоративной среде (данных много и они должны быть структурированы).

Почему "Passwork"? В 2020-м году мною было проведено исследование интернет-рынка, показавшее, что это оптимальный для наших относительно скромных задач выбор. Понравилась внешняя простота интерфейса пользователя и отсутствие избыточного функционала, нарастающего со временем в других менеджерах паролей. Также на чашу весов повлияло место происхождения - разработчики в российском городе Архангельск. Позже я сильно разочаровался в "Passwork" (вернее в его команде разработки и поддержки), о чём отдельно будет рассказано - в результате чего не рекомендую "Passwork" к использованию.

Последовательность дальнейших действий такова:

   [ уже посетило: 6230 / +2 ]   [ просмотреть в полном объеме ]

В связи с острой производственной необходимостью изыскания вменяемой замены месиву из текстовых файликов и KDBX-архивов, в коих обычно хранят свои пароли администраторы, разработчики и специалисты службы технической поддержки, занялся в 2020-м году поиском локально устанавливаемого web-сервиса, подходящего для небольшой команды из 50-ти специалистов, весьма активно занимающейся разработкой, внедрением и поддержкой информационных систем.

Воспользовавшись опубликованным в "Wikipedia" списком популярного программного обеспечения в классе "password manager" и просто поискав свежее в интернете, возымел мнение о ниже следующем.

Привожу список известных мне "парольных менеджеров", по возрастанию моих предпочтений, свежести разработки и только тех решений, что предлагают возможность установки полностью автономного сервера приложения в инфраструктуре клиента, с поддержкой аутентификации через LDAP.

   [ уже посетило: 6507 ]   [ просмотреть в полном объеме ]   [ есть комментарии: 9 ]

OS: "Microsoft Windows 8/10/2008/2012/2016/2019".
Apps: "rasdial", "rasphone", "taskschd.msc".

Задача: наладить подключение windows-системы к L2TP-серверу, с обязательным шифрованием VPN-трафика.

   [ уже посетило: 5169 ]   [ просмотреть в полном объеме ]

OS: "Linux Debian 9/10", "Linux Ubuntu Server 16/18/20 LTS".
Apps: "GnuPG", "s3cmd (Amazon AWS S3 client)", "Bash".

Задача: наладить полностью автоматизированную выгрузку файлов резервных копий из файловой системы linux-сервера во внешнее AWS:S3-хранилище, с обязательным шифрованием данных.

Прежде всего придумаем, какой тип шифрования мы хотим: ассиметричный или симметричный? С одной стороны, ассиметричное шифрование через сертификаты гибче при работе в многокомпонентной среде, позволяя обеспечить уровень безопасности ключа шифрования выше, нежели симметричное. А с другой стороны, наша задача проста и никаких изысков не подразумевает. Когда шифрование и расшифровка производятся в единственной точке доверенной среды (в которой уже имеются все файлы в незашифрованном состоянии), то в усложнении схемы управления ключами нет острой необходимости - достаточно быть бдительными и не выпускать "парольную фразу" за пределы доверенной зоны.

Учитывая то, что ради простоты мы остановились на симметричном шифровании, для осуществления такового само собой напрашивается инструмент "GnuPG/OpenPGP/PGP" (в случае ассиметричного шифрования наиболее вероятным выбором будет "OpenSSL").

В качестве хранилища данных будем использовать "Amazon AWS S3". Впрочем, идентичный протокол взаимодействия поддерживает ещё масса "облачных сервисов", вроде "Google CS", "DigitalOcean", "Dreamhost", "IBM COS S3", "Wasabi S3" - несложно будет задействовать их при необходимости.

   [ уже посетило: 3612 ]   [ просмотреть в полном объеме ]

Application: "Zabbix v3/4/5".

Задача: обеспечить техническую возможность отслеживать параметры источников бесперебойного питания посредством SNMP.

Источников бесперебойного питания множество, но модули контроля посредством SNMP по большей части имеют схожий набор основных параметров, который можно свести в один шаблон мониторинга. На основе предыдущего опыта и полученных с приобретённым оборудованием MIB-файлов мною сформирован шаблон "Template Module UPS General SNMPv2":

   [ уже посетило: 8367 ]   [ просмотреть в полном объеме ]

OS: "Linux Debian 8/9/10", "Linux Ubuntu Server 16/18/20 LTS".
Apps: "strongswan", "xl2tpd", "ip", "netplan".

Задача: наладить подключение linux-системы к L2TP-серверу, с обязательным шифрованием VPN-трафика.

Для справки: L2TP ("Layer 2 Tunneling Protocol") представляет собой сетевой протокол туннелирования канального уровня, сочетающий в себе протокол L2F ("Layer 2 Forwarding"), разработанный компанией "Cisco", и протокол PPTP корпорации "Microsoft". Позволяет организовывать VPN с заданными приоритетами доступа, однако не содержит в себе средств шифрования и механизмов аутентификации - потому для создания защищённой VPN его используют совместно с IPSec.

Для управления L2TP-соединениями воспользуемся подсистемой "xl2tpd", а для шифрования - "strongSwan".

Последовательность действий такова:

   [ уже посетило: 16641 / +2 ]   [ просмотреть в полном объеме ]

Выкладываю небольшой фотоотчёт с очередной велопоездки по Красноярску. Разноплановый маршрут получился, причём я его не планировал, а ехал буквально куда глаза глядят. Приключений не случилось, просто ехал через жару и пыль, вдыхая городской смог - надо бы завязывать с катанием по центру, а то это неполезно для здоровья, как мне кажется.

Далее только с фотографии с детальными подписями, чтобы понятнее было, где они сделаны.

   [ уже посетило: 2144 / +2 ]   [ изображения: 23 ]   [ просмотреть в полном объеме ]