OS: "Linux Debian 8/9/10", "Linux Ubuntu 18/20 LTS".
Application: "Bacula 5.2/7.4/9.0", "clickhouse-client".
Задача: наладить выгрузку резервной копии "баз данных" колоночной (column-oriented) СУБД "(Yandex) Clickhouse" посредством "Bacula".
Резервное копирование содержимого "баз данных" прямым копированием из файлов как правило невозможно и требуется предварительная выгрузка консистентного "дампа" в заранее известную директорию. Сделаем это, воспользовавшись встроенной возможностью "Bacula" исполнения произвольных скриптов на стороне клиента до и после процедуры непосредственного резервного копирования.
Для резервного копирования БД "Clickhouse" большого объёма, от сотен гигабайт до петабайт, лучше воспользоваться специализированными инструментами "clickhouse-copier" или "clickhouse-backup". В случае скромных размеров до сотни гигабайт вполне достаточно выгрузки конфигурации и данных в текстовых форматах SQL и TSV.
Bacula → Bacula + Clickhouse backup ( Резервное копирование БД "(Yandex) Clickhouse" посредством "Bacula". )
28 апреля 2021Web → Docker Registry ( Разворачиваем минимально функциональный сервер репозиториев docker-образов из эталонной реализации "Docker Registry", с простой HTTP-аутентификацией и web-интерфейсом "Docker Registry UI" для просмотра мета-данных и удаления ненужного )
1 марта 2021OS: "Linux Debian 9/10", "Linux Ubuntu Server 16/18/20 LTS".
Apps: "Nginx", "Let`s Encrypt", "Docker Registry", "Docker Registry UI", "Docker", "Docker Compose".
Задача: развернуть минимально функциональный сервер репозиториев docker-образов из эталонной реализации "Docker Registry", с простой HTTP-аутентификацией и web-интерфейсом "Docker Registry UI" для просмотра мета-данных и удаления ненужного.
Всё просто - последовательно делаем следующее:
Apps: "Nginx", "Let`s Encrypt", "Docker Registry", "Docker Registry UI", "Docker", "Docker Compose".
Задача: развернуть минимально функциональный сервер репозиториев docker-образов из эталонной реализации "Docker Registry", с простой HTTP-аутентификацией и web-интерфейсом "Docker Registry UI" для просмотра мета-данных и удаления ненужного.
Всё просто - последовательно делаем следующее:
1. Подготовка системного окружения (отдельная инструкция);
2. Установка системы контейнеризации "Docker" (отдельная инструкция);
3. Установка сопутствующего ПО и подготовка конфигурации;
4. Подготовка среды и запрос "Let`s Encrypt" SSL-сертификатов;
5. Подготовка конфигурации для фронтального web-сервера "Nginx";
6. Наладка запуска посредством "Docker Compose";
7. Настройка автозапуска "Docker Compose" посредством "Systemd";
8. Проверка функциональности docker-репозитория;
9. Удаление контейнеров из регистра посредством "docker API";
10. Автоматизация очистки от ненужных данных в "Docker Registry".
2. Установка системы контейнеризации "Docker" (отдельная инструкция);
3. Установка сопутствующего ПО и подготовка конфигурации;
4. Подготовка среды и запрос "Let`s Encrypt" SSL-сертификатов;
5. Подготовка конфигурации для фронтального web-сервера "Nginx";
6. Наладка запуска посредством "Docker Compose";
7. Настройка автозапуска "Docker Compose" посредством "Systemd";
8. Проверка функциональности docker-репозитория;
9. Удаление контейнеров из регистра посредством "docker API";
10. Автоматизация очистки от ненужных данных в "Docker Registry".
Web → Sonatype Nexus ( Развёртываем сервер репозиториев артефактов "Nexus Repository Manager" для хранения docker-образов и nuget-библиотек. )
25 февраля 2021OS: "Linux Debian 9/10", "Linux Ubuntu Server 16/18/20 LTS".
Apps: "Nginx", "Nexus RM", "Docker", "Docker Compose", LDAP.
Задача: развернуть сервер репозиториев артефактов "Sonatype Nexus Repository Manager v3 (OSS)", настроив его для хранения docker-образов и nuget-библиотек.
Последовательность дальнейших действий такова:
Apps: "Nginx", "Nexus RM", "Docker", "Docker Compose", LDAP.
Задача: развернуть сервер репозиториев артефактов "Sonatype Nexus Repository Manager v3 (OSS)", настроив его для хранения docker-образов и nuget-библиотек.
Последовательность дальнейших действий такова:
1. Подготовка системного окружения (отдельная инструкция);
2. Установка системы контейнеризации "Docker" (отдельная инструкция);
3. Установка сопутствующего ПО и подготовка конфигурации;
4. Подготовка конфигурации для фронтального web-сервера "Nginx";
5. Наладка запуска посредством "Docker Compose" и "Systemd";
6. Конфигурирование web-приложения "Nexus Repository Manager v3 (OSS)";
7. Проверка функциональности docker-репозитория;
8. Интеграция с внешним LDAP/AD для аутентификации.
2. Установка системы контейнеризации "Docker" (отдельная инструкция);
3. Установка сопутствующего ПО и подготовка конфигурации;
4. Подготовка конфигурации для фронтального web-сервера "Nginx";
5. Наладка запуска посредством "Docker Compose" и "Systemd";
6. Конфигурирование web-приложения "Nexus Repository Manager v3 (OSS)";
7. Проверка функциональности docker-репозитория;
8. Интеграция с внешним LDAP/AD для аутентификации.
Jenkins → Slave + Cygwin + OpenSSH ( Подключение агентов исполнения "Jenkins Slaves" в операционных системах "MS Windows" в среде "Java 11+", через SSH-подключение. )
18 февраля 2021OS: "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", в любом случае необходимой.
Последовательность дальнейших действий такова:
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", в любом случае необходимой.
Последовательность дальнейших действий такова:
1. Установка "OpenSSH Server" и "Syslog-NG";
2. Настройка подсистемы журналирования "(cygwin) Syslog-NG";
3. Настройка сервера "(cygwin) OpenSSH Server";
4. Об интеграции и пользователях "(cygwin) OpenSSH Server";
5. Наладка аутентификации пользователей "(cygwin) OpenSSH Server" по ssh-ключу;
6. Установка среды исполнения "Java/OpenJDK" в ОС "MS Windows";
7. Подключение "Jenkins Slave" через "(cygwin) OpenSSH Server" на ОС "MS Windows";
8. Проверка работоспособности "Jenkins Slave" через простейшую задачу типа "Pipeline".
2. Настройка подсистемы журналирования "(cygwin) Syslog-NG";
3. Настройка сервера "(cygwin) OpenSSH Server";
4. Об интеграции и пользователях "(cygwin) OpenSSH Server";
5. Наладка аутентификации пользователей "(cygwin) OpenSSH Server" по ssh-ключу;
6. Установка среды исполнения "Java/OpenJDK" в ОС "MS Windows";
7. Подключение "Jenkins Slave" через "(cygwin) OpenSSH Server" на ОС "MS Windows";
8. Проверка работоспособности "Jenkins Slave" через простейшую задачу типа "Pipeline".
Jenkins → Docker + Jenkins ( Развёртывание несколько инстансов "Jenkins" в среде контейнеризации "Docker" с целью изоляции процедур CI/CD раздельно работающих команд разработки. )
4 февраля 2021OS: "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" хорошо расписан (здесь и здесь, с вариациями), так что просто сделаем это.
Последовательность дальнейших действий такова:
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" хорошо расписан (здесь и здесь, с вариациями), так что просто сделаем это.
Последовательность дальнейших действий такова:
1. Подготовка системного окружения (отдельная инструкция);
2. Установка системы контейнеризации "Docker" (отдельная инструкция);
3. Подготовка несущей файловой структуры для приложений "Jenkins";
4. Модификация официального docker-образа "Jenkins";
5. Подготовка среды и запрос "Let`s Encrypt" SSL-сертификатов;
6. Подготовка конфигурации для фронтального web-сервера "Nginx";
7. Наладка запуска посредством "Docker Compose" и "Systemd";
8. Конфигурирование инстансов web-приложения "Jenkins".
2. Установка системы контейнеризации "Docker" (отдельная инструкция);
3. Подготовка несущей файловой структуры для приложений "Jenkins";
4. Модификация официального docker-образа "Jenkins";
5. Подготовка среды и запрос "Let`s Encrypt" SSL-сертификатов;
6. Подготовка конфигурации для фронтального web-сервера "Nginx";
7. Наладка запуска посредством "Docker Compose" и "Systemd";
8. Конфигурирование инстансов web-приложения "Jenkins".
Jenkins → Почему Jenkins? ( Рассуждения о причинах выбора "Jenkins" в качестве CI/CD-сервиса в корпоративной среде. )
14 января 2021Некоторое время у меня не было определённости, каким инструментарием управлять процессами 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" фактически попросту отказались заниматься.
Прежде всего, в случае использования "GitLab", для управления удалёнными стендами сборки (CI) и серверами развёртывания (CD) понадобится постоянное прямое соединение с центром управления, что делает схему небезопасной в том смысле, что к хранилищу исходного кода придётся организовать доступ отовсюду - надо оно на самом деле, или нет. Таким образом, в корпоративной среде сервис CI/CD должен быть реализован в виде отдельного сервера, чтобы минимизировать прямые бесконтрольные соединения с хранилищем репозиториев кода.
В процессе тестирования разных вариантов использования выявлено, что "GitLab" откровенно заточен под программные продукты на "Linux" и "MacOS", настолько, что для агента исполнения "GitLab Runner" в "Microsoft Windows" даже отображение символов национальных кодировок (русской, например) журнала событий простыми методами невозможно настроить - для "Linux" и "MacOS" без проблем, а вот транскодированием комбинаций "cp866", "cp1251" и "utf8" разработчики "GitLab" фактически попросту отказались заниматься.
Web → Passwork ( Развёртывание в среде исполнения "Docker" web-приложения "Passwork", предназначенного для хранения и управления паролями в корпоративной среде. )
25 сентября 2020OS: "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" к использованию.
Последовательность дальнейших действий такова:
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" к использованию.
Последовательность дальнейших действий такова:
1. Подготовка системного окружения (отдельная инструкция);
2. Установка системы контейнеризации "Docker" (отдельная инструкция);
3. Установка сопутствующего ПО и подготовка конфигурации;
4. Загрузка и развёртывание из репозитория приложения "Passwork";
5. Подготовка специализированного docker-образа PHP-интерпретатора для "Passwork";
6. Подготовка конфигурации СУБД "MongoDB";
7. Подготовка конфигурации почтовой подсистемы;
8. Установка и настройка фронтального web-сервера "Nginx";
9. Наладка запуска посредством "Docker Compose" и "Systemd";
10. Подготовка СУБД "MongoDB" и создание БД для "Passwork";
11. Первоначальная настройка web-приложения "Passwork";
12. Ограничение межсетевых взаимодействий посредством "IPtables".
2. Установка системы контейнеризации "Docker" (отдельная инструкция);
3. Установка сопутствующего ПО и подготовка конфигурации;
4. Загрузка и развёртывание из репозитория приложения "Passwork";
5. Подготовка специализированного docker-образа PHP-интерпретатора для "Passwork";
6. Подготовка конфигурации СУБД "MongoDB";
7. Подготовка конфигурации почтовой подсистемы;
8. Установка и настройка фронтального web-сервера "Nginx";
9. Наладка запуска посредством "Docker Compose" и "Systemd";
10. Подготовка СУБД "MongoDB" и создание БД для "Passwork";
11. Первоначальная настройка web-приложения "Passwork";
12. Ограничение межсетевых взаимодействий посредством "IPtables".
Passwork → Менеджеры паролей ( Перечень "парольных менеджеров", кандидатов на использование в корпоративной среде. )
25 сентября 2020В связи с острой производственной необходимостью изыскания вменяемой замены месиву из текстовых файликов и KDBX-архивов, в коих обычно хранят свои пароли администраторы, разработчики и специалисты службы технической поддержки, занялся в 2020-м году поиском локально устанавливаемого web-сервиса, подходящего для небольшой команды из 50-ти специалистов, весьма активно занимающейся разработкой, внедрением и поддержкой информационных систем.
Воспользовавшись опубликованным в "Wikipedia" списком популярного программного обеспечения в классе "password manager" и просто поискав свежее в интернете, возымел мнение о ниже следующем.
Привожу список известных мне "парольных менеджеров", по возрастанию моих предпочтений, свежести разработки и только тех решений, что предлагают возможность установки полностью автономного сервера приложения в инфраструктуре клиента, с поддержкой аутентификации через LDAP.
Воспользовавшись опубликованным в "Wikipedia" списком популярного программного обеспечения в классе "password manager" и просто поискав свежее в интернете, возымел мнение о ниже следующем.
Привожу список известных мне "парольных менеджеров", по возрастанию моих предпочтений, свежести разработки и только тех решений, что предлагают возможность установки полностью автономного сервера приложения в инфраструктуре клиента, с поддержкой аутентификации через LDAP.
Connection → MS Windows + L2TP + IPsec ( Попытка наладить подключение windows-системы к L2TP-серверу, с обязательным шифрованием VPN-трафика. )
17 сентября 2020OS: "Microsoft Windows 8/10/2008/2012/2016/2019".
Apps: "rasdial", "rasphone", "taskschd.msc".
Задача: наладить подключение windows-системы к L2TP-серверу, с обязательным шифрованием VPN-трафика.
Apps: "rasdial", "rasphone", "taskschd.msc".
Задача: наладить подключение windows-системы к L2TP-серверу, с обязательным шифрованием VPN-трафика.
К сожалению, сразу отмечу, что задача создания стабильного VPN-туннеля посредством L2TP+IPsec из операционных систем "MS Windows" оказалась для меня невыполнимой. Реализация протокола L2TP в современных "MS Windows" отвратительно нестабильна. Ежедневно соединение рвалось раз по десять, при том, что соседние (буквально стоящие бок о бок, с идентичным сетевым подключением) linux-серверы и маршрутизаторы "Cisco" или "Mikrotik" удерживали связь месяцами, без единого сбоя. Публикую это на память, а не как руководство к действию.
Backup → S3 + PGP synchronization ( Налаживаем автоматизированную выгрузку резервных копий из файловой системы во внешнее AWS:S3-хранилище, с обязательным шифрованием данных. )
14 сентября 2020OS: "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" - несложно будет задействовать их при необходимости.
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" - несложно будет задействовать их при необходимости.