Sonatype Nexus — программный продукт, который представляет собой менеджер репозиториев для хранения артефактов. По умолчанию установка происходит без включенного SSL. В данной статье будет описана установка Sonatype Nexus в контейнере Docker с использованием Nginx в качестве обратного прокси сервера, а также будет рассмотрено получение бесплатного доменного имени на сайте freenom.com и создание SSL-сертификата при помощи службы Let’s Encrypt.
При настройке CI/CD для приложений мы в компании, как правило, используем Vault от HashiCorp. К тому же сами приложения зачастую используют Vault для хранения секретных данных. Но для того, чтобы начать использовать Vault, сначала необходимо произвести его настройку. Раньше нам приходилось вручную производить подобные манипуляции для каждого проекта, что отнимало немало времени. Найти готовый модуль, который подошел бы нам, не удалось. Поэтому мы написали свой terraform-модуль, который позволяет автоматизировать данный процесс.
На текущий момент созданный нами terraform-модуль покрывает все наши требования, но в дальнейшем он будет дорабатываться. Модуль позволяет создавать политики доступа и хранилища секретов, включать необходимые способы авторизации (certs, jwt, oidc, kubernetes и т.д.), создавать токены, jwt/oidc/token-роли и идентификационные группы. Также при помощи него можно генерировать TLS-сертификаты и jwt ключи в определенной директории.
yarsync - Yet Another Rsync - предназначен для синхронизации данных между несколькими устройствами, более точно - между файловыми системами в Unix-подобных средах. yarsync обладает интерфейсом, похожим на git, и является Python-обёрткой вокруг программы rsync. Программа доступна под свободной лицензией GPL v3.0 на github (я автор).
yarsync работает там, где есть Питон и rsync.
Данные могут синхронизироваться локально или между разными компьютерами (в таком случае на удалённой машине также должен быть установлен rsync). Кроме того, файловые системы должны поддерживать жёсткие ссылки (hard links). Популярные системы, поддерживающие жёсткие ссылки - ext2-ext4, HFS+, а также NTFS. Не поддерживают жёсткие ссылки FAT, exFAT (часто используемые на флеш-накопителях).
Говоря простыми словами, допустим, что у вас есть компьютеры дома и на даче. У вас есть папка с книгами и статьями по программированию, которые вы собирали долгие годы, и которой регулярно пользуетесь (её копиями на разных машинах). Вы хотите, чтобы эти копии были одинаковы - то есть в идеале чтобы можно было работать с данными на разных компьютерах (добавлять новые статьи, удалять ненужные, переименовывать и перемещать файлы и папки), а затем эти изменения легко переносились на другие копии. Это и делает yarsync, отслеживая изменения и позволяя эффективно синхронизировать данные через доступный сервер или внешний накопитель (жёсткий диск).
Примерно 20 лет назад была установлена СУБД Firebird, если не ошибаюсь, версии 1.0.3, на сегодняшний день база все еще жива и нужна, размер ее перевалил за 30ГБ, что по сегодняшним меркам очень мало, но и основной рост базы пришелся на начало века.
С повсеместным внедрением средств мониторинга захотелось снимать минимальную статистику и определять работоспособность СУБД и самой БД. Для мониторинга использую Zabbix установленный на Ubuntu 20.04 LTS, а сама СУБД находится на виртуальной машине с Windows 2008 Server. Версии на которых был использован метод мониторинга описанный ниже для СУБД Firebird 2.5.9, версия Zabbix 6.0. Но думаю что и с другими версиями проблем быть не должно.
Настройка LEMP сервера с помощью docker для простых проектов. Часть первая: База
Мы продолжаем цикл обучающих статей для начинающих системных администраторов. В серии "Настройка LEMP сервера с помощью docker для простых проектов" мы разберем docker и docker-compose, рассмотрим, как поднять стек LAMP+Nginx с помощью docker, а также расскажем вам, в чем преимущество контейнеризации и виртуализации.
Старт любого нашего проекта начинается с подготовки инфраструктуры. Времени на это порой уходит довольно много. Как минимум необходимо нарезать виртуалки или донастроить Kubernetes, настроить CI, базы данных, логирование, мониторинг и прочие компоненты. В лучшем случае в этих заботах проходит несколько дней, а ни строчки кода еще не написано. Знакомая ситуация?
В данной статье я опишу свой опыт миграции домашнего сервера на гипервизоре Hyper-V, установленного на Windows Server 2012 R2, на гипервизор Xen Project 4.14, установленного на Debian 11. Я ни в коем случае не являюсь экспертом в Linux, всю свою карьеру в основном использовал операционные системы Microsoft, но времена и технологии меняются, и нужно соответствовать.
Зачем мне нужен домашний сервер? Для меня — это во многом песочница, где я могу исследовать и пробовать технологии, которые не могу потестировать на десктопе. Помимо этого, конечно, он несёт и утилитарные функции: контроллер домена, файловый сервер, хостинг для сайта моей жены, TFS-сервер (да, до сих пор, но собираюсь поменять на GitLab) и др. Всё это разложено по виртуалкам для более эффективного управления и использования ресурсов. Разворачивал я Hyper-V версию лет 7 назад, с тех пор существенных изменений не производил, однако, какое-то время назад, решил мигрировать его на Linux. Наконец-то у меня дошли руки до этого. В этой статье собран мой опыт «не совсем новичка» в Linux (ранее опыт ограничивался в основном использованием Ubuntu в WSL) и платформах виртуализации (Hyper-V, VMWare).
Для меня всё, описанное в данной статье, — прежде всего, мой практический опыт, без которого любая теория — ничто. Для новичков, думаю, подробность повествования даст хорошее понимание принципов работы с Linux.
Привет, Хабр! Меня зовут Кирилл Орлов, и я занимаюсь вопросами ИБ в Oxygen. В этом посте предлагаю посмотреть "в глаза" трём самым популярным ИБ угрозам - и разобрать, почему миграция в облако помогает справиться с ними быстрее и проще. Сегодня я не буду лезть в дебри ИБ и разбирать сложные кейсы. Этот текст скорее предназначен для новичков в ИБ, которым стараются сложить (или уже сложили) на плечи вопросы защиты данных в дополнение к администрированию или другим обязанностям. Если это про вас, то заходите под кат, давайте обсудим, как перенос корпоративных систем в облако мог бы помочь вам с решением проблем кибербезопасности.
Эта история началась весной 2021 года.
Я много работал с Docker-контейнерами под Windows и страдал.
Страдал от того, как медленно запускается Docker Desktop.
Страдал от того, сколько он ест оперативной памяти.
Страдал от того, что постоянно что-то ломалось при обновлениях.
Страдал от того, что на Windows Server надо устанавливать Docker через какой-то особенный механизм, не работающий через proxy и не работающий на Windows Server 2016. Причём в связи с тем, что Docker Inc. передала enterprise-сервис компании Mirantis, этот способ через какое-то время вообще перестанет работать. В результате вы получаете Docker, собранный из непонятно каких исходников. Всё, что про них известно — они точно не такие, как в Docker Desktop. Вообще, для инструмента, задача которого — просто скачать один единственный пакет и установить его, в трекере задач этого проекта на удивление много багов.
Страдал от того, что Docker Desktop прекратил поддержку Windows 10 LTSC 2019, которая продолжает поддерживаться Microsoft вплоть до 2024 года (а расширенная поддержка — аж до 2029).
И я спросил себя: а почему, за что, как так? Есть ли какая-то такая фундаментальная причина, по которой софт, решающий эту задачу, обязан доставлять столько неудобств? И не нашёл её.
А потому подошел к проблеме по принципу: если тебя что-то не устраивает, сделай это лучше.
После чего быстренько придумал название проекту и создал репозиторий.
Привет, Хабр! Меня зовут Андрей Благов, я архитектор центра профессиональных сервисов и R&D в облачном провайдере T1 Cloud, и сегодня речь пойдет о сертификатах SSL. Добавляйте статью в закладки, она вам точно пригодится. В ней я поделюсь PowerShell-скриптами для проверки действительности SSL-сертификатов.
А если ваш отдел мониторинга не находит на вас время, но перед вами стоит задача автоматизировать рутинные процессы — подписывайтесь на наш блог. В дальнейшем я планирую делиться личным опытом и рассказывать о том, как с помощью PowerShell можно наладить выгрузки отчетов, создавать проверки и оповещения по различным условиям.
Немного о том, что из себя представляет виртуальная АТС, какова её роль в офисной среде, а также о технических и интеграционных возможностях одного из самых продвинутых и актуальных решений в этой области.
В наше время проблема анонимности стоит очень остро, с каждым днем пользователи сети все больше стараются заботиться о своей цифровой гигиене и сохранения конфиденциальной информации таковой. Поэтому я решил сделать обзор популярных (и не очень) поисковиков, на сколько они соответствуют ожиданиям пользователей.
Привет, Хабр! Сергей Бондарев, архитектор Southbridge и спикер в Слёрме, недавно провёл вебинар «Kubernetes'22: выбор между self-hosted и managed-решением». Сегодня публикуем текстовую версию вебинара.
В предыдущих частях я сделал кубики, из которых состоит serverless приложение:
Часть 1. Первые шаги. Первая лямбда
Реализовано 4 функции, развернута БД. Функции интегрированы с БД, запускаются локально в режиме отладки. Вся инфраструктура поднимается буквально с помощью нескольких SAM команд.
Но пока это мало похоже на какое-то целостное приложение, т.к. у приложения нет API. Мои лямбда функции не умеют обрабатывать http запросы. Так что в этой части займусь вопросами, связанными с построениями настоящего API. Также сделаю интеграцию с github api.
В одном из проектов перед нами встала нетривиальная задача описать современную разработку ПО в виде некой технологической платформы. Что обязательно должно в нее входить, какие задачи решать? Не ограничившись стандартной восьмеркой DevOps, мы составили довольно подробную матрицу функциональности, пытаясь описать вообще все. Потом по ней хотим разложить используемое ПО и навести полный порядок. Посмотрите, ничего мы не забыли?
Современная разработка ПО в нашем понимании - это хорошо отлаженный DevSecOps с максимумом автоматизации, который опирается на облачную инфраструктуру. Считаем, что инфраструктура, включая контейнеризацию, есть и готова под любые наши хотелки. А вот что находится выше?
Стандартную восьмерку DevOps вы все видели, вот она.
Event system architecture (EDA)
Ещё одна из популярных архитектур — Event system architecture (EDA), что в переводе на русский означает “архитектура на основе событий”. Суть данной архитектуры состоит в том, что приложение работает с событиями (эвентами), которые генерируются пользователем или другими системами.
Предположим, у нас есть метод для обновления локации пользователей в нашей базе данных. В таком случае стандартный запрос будет выглядеть следующим образом: