Для того, чтобы понять как работают простые команды Ansible, приведу несколько простых примеров. По аналоги вы всегда сможете придумать свои команды под ваши конкретные ситуации.
2.1. Проверка связи.
С помощью Ansible можно одновременно выполнить одну задачу на целой группе серверов.
Модуль ping проверит, есть ли у вас валидные учетные данные для подключения к нодам, определенным в файле инвентаря, и может ли Ansible запускать сценарии Python на удаленном сервере от имени root пользователя.
2.1.1. Со всеми нодами.
Чтобы убедиться, что Ansible может подключаться к нодам и запускать команды и плейбуки, вы можете использовать следующую команду:
# ansible all -m ping
Ответ pong означает, что Ansible готов запускать команды и плейбуки на этой ноде.
Ответ:
2.1.2. С целевыми хостами.
Проверять с целевыми хостами можно и поштучно через их алиасы:
Сервер Ansible: CentOS Linux release 7.9.2009 (Core).
Node 1: CentOS Linux release 7.9.2009 (Core).
Node 2: CentOS Linux release 7.9.2009 (Core).
Node 3: CentOS Linux release 7.9.2009 (Core).
1. Введение.
Представьте себе, что вам нужно управлять парком серверов, расположенных к тому же в разных географических точках. Каждый из этих серверов требует настройки, регулярного обновления и мониторинга. Конечно, для решения этих задач можно воспользоваться самым простым способом: подключиться к каждому серверу по ssh и внести необходимые изменения. При всей своей простоте этот способ сопряжен с некоторыми трудностями: он чрезвычайно трудоемок, а на выполнение однообразных операций уходит очень много времени.
Чтобы упростить процессы настройки и конфигурирования серверов, можно также писать shell-скрипты, но и этот способ вряд ли можно назвать совершенным. Скрипты нужно постоянно изменять, подстраивая их под каждую новую задачу. При их написании необходимо учитывать различие операционных систем и версий. Не будем забывать и о том, что отладка скриптов отнимает много усилий и забирает немало времени.
Оптимальным вариантом решения описанных проблем является внедрение системы удаленного управления конфигурацией. В таких системах достаточно лишь описать нужное состояние управляемого узла. Система должна сама определить, что нужно сделать для достижения этого состояния, и осуществит все необходимые действия.
Со всеми сложностями, о которых идет речь выше, вы наверняка хорошо знакомы на собственном опыте: у вас имеется несколько десятков серверов, расположенных в разных точках планеты. На них необходимо регулярно вносить различные изменения: обновлять операционную систему, устанавливать и обновлять различное программное обеспечение, изменять конфигурацию и тому подобное.
Предлагается все эти операции автоматизировать и внедрить систему удаленного управления конфигурациями.
Так как простые задачи для Ansible реально простые, в буквальном смысле слова, то я принял решение вынести их в отдельную инструкцию:
Ansible — программное решение для удаленного управления конфигурациями, разработанное Майклом Де Хаанном в 2012 году. Название продукта взято из научно-фантастической литературы: в романах американской писательницы Урсулы Ле Гуин была такая штука, как Ansible — это устройство для оперативной космической связи.
Ansible — мощное программное обеспечение автоматизации конфигурирования, с открытым исходным кодом, управления и развертывания приложений на узлах без каких-либо простоев, для работы которого потребуется только SSH. В отличие от подобных продуктов, Ansible устанавливается на единственном хосте, который может даже быть вашей локальной машиной и использует SSH для связи с каждым удаленным узлом. Это позволяет ему быть невероятно быстрым при конфигурировании новых серверов, поскольку не требуются предварительно установленные дополнительные пакеты на каждом новом сервере.
Машина управления, где установлен Ansible и Узлы, управляемая этой машиной по SSH. Местоположение узлов определяется управляющей машиной через её инструментарий. Ansible не требует установки клиентской части или приложения, что означает отсутствие необходимости какой-либо установки агента на удаленных узлах, так что это означает, что нет каких-либо фоновых демонов или программ, выполняемых для Ansible, когда он не управляет узлами.
Другими словами, Ansible — программное обеспечение для централизованного управления конфигурациями, то есть другими операционными системами и установленными на них программами. Это современный инструмент управления конфигурацией, который облегчает задачу настройки и обслуживания удаленных серверов.
Ansible берет на себя всю работу по приведению удаленных серверов в необходимое состояние. Администратору необходимо лишь описать, как достичь этого состояния с помощью так называемых сценариев — специальных файлов «playbook».
В них описывается желаемое состояние управляемой системы, например, необходимо наличие пакета Midnight Commander. Ansible проверяет, соответствует ли удаленный компьютер описанию в плейбуке, и если это не так, приводит его в должный вид. Формат для playbook — YAML. Для описания задачи задается ее имя, используемый модуль и список параметров.
Такая технология позволяет очень быстро осуществлять переконфигурирование системы, для этого достаточно всего лишь добавить несколько новых строк в сценарий.
Пример плейбука:
---
- name: Nginx web server
hosts: web-servers
remote_user: root
tasks:
- name: Installs nginx web server
yum:
pkg: nginx
state: installed
update_cache: true
- name: Push future default virtual host configuration
copy:
src: files/site.conf
dest: /etc/nginx/conf.d/
mode: 0640
В данном примере мы задаем 2 задачи для группы серверов web-servers — сначала необходимо установить пакет nginx, затем скопировать файл site.conf с сервера на удаленную систему в каталог /etc/nginx/conf.d.
3. Почему Ansible лучше других подобных программ?
По сравнению с другими популярными инструментами автоматизации IT-инфраструктуры, Ansible не требует установки клиентских приложений на обслуживаемые сервера, что может сократить время настройки перед развертыванием инфраструктуры. Для работы Ansible подключается к обслуживаемым серверам по SSH.
Преимущества Ansible по сравнению с другими аналогичными решениями (здесь в первую очередь следует назвать такие продукты, как Puppet, Chef и Salt) заключаются в следующем:
на управляемые узлы не нужно устанавливать никакого дополнительного программного оборудования, всё работает через SSH (в случае необходимости дополнительные модули можно взять из официального репозитория);
код программы, написанный на Python, очень прост;
при необходимости написание дополнительных модулей не составляет особого труда;
язык, на котором пишутся сценарии, также предельно прост;
низкий порог вхождения: обучиться работе с Ansible можно за очень короткое время;
документация к продукту написана очень подробно и вместе с тем — просто и понятно;
документация регулярно обновляется;
Ansible работает не только в режиме push, но и pull, как это делают большинство систем управления (Puppet, Chef);
имеется возможность последовательного обновления состояния узлов (rolling update).
Самостоятельно ознакомиться с Puppet вы можете по моим инструкциям на этом же сайте:
“Из коробки” все сценарии и команды выполняются методом push: когда возникает необходимость, мы запускаем сценарий, и он последовательно выполняется на удалённых серверах. Однако разработчики также предусмотрели метод pull и даже написали специальное приложение для установки необходимой для этого части ansible на удалённые хосты.
5. Как работает Ansible.
Основная идея Ansible – наличие одного или нескольких управляющих серверов, из которых вы можете отправлять команды или наборы последовательных инструкций (playbooks) на удаленные сервера, подключаясь к ним по SSH.
Файл Host inventory содержит информацию об обслуживаемых серверах, где команды будут исполнены. Файл конфигурации Ansible может быть полезен для указания настроек вашего окружения.
Наборы инструкций (playbooks) состоят из одной или более задач, которые описываются с помощью функциональность модуля ядра Ansible или сторонних модулей, которые могут потребоваться в специфических ситуациях. Сами по себе наборы инструкций — последовательные наборы команд, в которых могут быть проверки условий: если условие не выполняется, определенные команды могут пропускаться.
Также вы можете использовать Ansible API для запуска скриптов. Если скрипту-обертке (wrapper) может потребоваться запуск playbook, это можно сделать через API. Сами playbooks описываются декларативно в формате YAML. Ansible поддерживает сценарии развертывания новых облачных серверов и конфигурирования их на основании ролей. Часть работы может быть проведена в локальном режиме на управляющем сервере, а остальная — на созданном сервере после его первой загрузки.
6. Краткий словарь терминов Ansible.
В этом этой инструкции широко используются такие термины Ansible:
Control Machine или Node — ведущая система, в которой установлен Ansible и откуда он может подключаться к нодам и выполнять на них команды.
Хост — в Ansible хост — это удаленный компьютер, которому назначены отдельные переменные, и они далее группируются вместе. У каждого хоста есть выделенное имя или уникальный IP-адрес, чтобы сделать его идентификацию легкой и быстрой. Им также может быть присвоен простой номер порта, если вам не нужно обращаться к ним через соединение ssh.
Нода или Узел — сервер, управляемый Ansible.
Файл инвентаря — файл, который содержит информацию о серверах, которыми управляет Ansible, обычно находится в /etc/ansible/hosts.
Playbooks — они написаны на языке программирования YAML с минимальным синтаксисом и обычно используются для автоматизации задач при необходимости.
Роль — коллекция плейбуков и других файлов, которые имеют отношение к цели. Например, к установке web-сервера.
Play — полный набор инструкций Ansible. В play может быть несколько плейбуков и ролей, включенных в один плейбук, который служит точкой входа.
Задача — каждая инструкция, определенная в книге игр, называется задачей, которая будет выполняться в дальнейшем для выполнения действия.
Факты — они выводятся из удаленных узлов автоматически при выполнении модулей на удаленных узлах.
Группа — это комбинация хостов, которые назначены пулу, и переменные также могут совместно использоваться.
Инвентаризация — инвентаризация является важным компонентом ANSI удаленного механизма, который описывает хосты, группы и так далее. С помощью IP-адреса или номера порта и так далее. Таким образом, вы можете определить все хосты в одном файле для быстрого доступа.
API — это транспортная среда для различных облачных сервисов, как частных, так и общедоступных.
Модули — с помощью playbook модули могут быть выполнены на удаленных узлах напрямую. Кроме того, его можно использовать для управления службами, ресурсами, пакетами, файлами или командами и так далее. Модули являются основными компонентами, которые помогают устанавливать пакеты, позволяют API-интерфейсам взаимодействовать друг с другом и планировать действия для системных файлов. В Ansible есть множество модулей, которые запрограммированы для автоматизации практически всего внутри инструмента.
Плагины — это специальные части кода, которые помогают быстро писать код. Плагины автоматизируют задачи разработки и помогают максимально ускорить работу по развертыванию. Ansible оснащен различными удобными плагинами, которые можно использовать при необходимости, чтобы упростить вам задачу.
Оркестровка — это общий термин, который часто используется в техническом мире. Почему это важно и в Ansible? Для разных программных продуктов значение оркестровки может быть различным. Ansible использует его в качестве дирижера для управления оркестром.
7. Установка.
Обновим операционную систему:
# yum -y update && yum -y upgrade
По умолчанию Ansible нет в репозитории CentOS 7 — устанавливаем репозиторий EPEL:
# yum -y install epel-release
После устанавливаем сам сервер управления:
# yum -y install ansible
Где система автоматически обновит список пакетов с учетом нового репозитория и начнет установку Ansible.
Проверка версии установленной версии Ansible:
# rpm -qa | grep ansible
Ответ:
или
# ansible --version
Ответ:
8. Настройка Ansible.
Файл конфигурации описывается в INI–формате. Вы можете переопределить часть или всю конфигурацию в параметрах playbook или переменных окружения.
При исполнении команд Ansible проверяет наличие файла конфигурации в следующих расположениях:
проверяется переменная окружения ANSIBLE_CONFIG, которая может указывать на файл конфигурации;
./ansible.cfg – в текущей директории;
~/.ansible.cfg — в домашней директории;
/etc/ansible/ansible.cfg — в каталоге, сгенерированном при установке Ansible через менеджер пакетов.
9. Настройка через переменные окружения.
Большинство параметров конфигурации можно установить через переменные окружения, используя префикс ANSIBLE_ перед названием параметра конфигурации (большими буквами).
Например:
export ANSIBLE_SUDO_USER=root
После этого переменная ANSIBLE_SUDO_USER может быть использована в playbook.
10. Параметры конфигурации.
Параметров конфигурации Ansible множество.
Давайте рассмотрим некоторые из них:
hostfile: Параметр указывает на путь к inventory file, в котором содержится список адресов хостов, к которым Ansible может подключиться.
Например: hostfile = /etc/ansible/hosts
library: Путь к директории, где хранятся модули Ansible.
Например: library = /usr/share/ansible
forks: Количество процессов, которые может породить Ansible. По умолчанию установлено 5 процессов.
Например: forks = 5
sudo_user: Пользователь по умолчанию, от которого Ansible запускает команды на удаленных серверах.
Например: sudo_user = root
remote_port: Порт для соединения по SSH (по умолчанию 22).
Например: remote_port = 22
host_key_checking: Параметр позволяет отключить проверку SSH-ключа на хосте. По умолчанию проверка выполняется.
Например: host_key_checking = False
timeout: Значение таймаута попытки подключения по SSH.
Например: timeout = 60
log_path: Путь для хранения файлов логов. По умолчанию Ansible не хранит их совсем, но указав этот параметр можно активировать запись логов.
Например: log_path = /var/log/ansible.log
11. Файл конфигурации ansible.cfg.
По умолчанию список хостов/групп, к которым применяются команды содержится в файле /etc/ansible/hosts:
# grep -E '^#inventory' /etc/ansible/ansible.cfg
Ответ:
При необходимости его можно переопределить с помощью опции
--inventory-file(-i)
Пример создания кастомного файла конфигурации.
Подключитесь по SSH к созданному управляющему серверу с установленным Ansible.
Создайте директорию для экспериментов ‘ansible‘ в своём домашнем каталоге и перейдите в него:
# mkdir ~/ansible
# cd ~/ansible
Также создайте каталог для хранения модулей Ansible и каталог для хранения логов:
# mkdir ~/ansible/modules
# mkdir ~/ansible/logs
Создайте файл ansible.cfg со следующим содержимым:
Для экспериментов можно упомянуть, к примеру пару серверов, которые и можно настраивать.
Нужно сообщить Ansible их адреса и сгруппировать их.
Для этого создайте файл inventory в директории ~/ansible/inventory со следующим содержимым:
[experiments]
ip_первой_машины
ip_второй_машины
12. Файл hosts.
Работа с Ansible начинается с настройки его центрального файла списка хостов — так и называется файл hosts.
По умолчанию расположение файла — /etc/ansible/hosts, но оно может также быть задано параметром окружения $ANSIBLE_HOSTS или параметром -i при запуске ansible и ansible-playbook.
Содержимое этого файла может выглядеть, например, так, в квадратных скобках указаны имена групп управляемых узлов, ниже перечисляются входящие в эти группы серверы:
Помимо списка управляемых узлов, в файле hosts могут быть указаны и другие сведения, необходимые для работы: номера портов для подключения по SSH, способ подключения, пароль для подключения по SSH, имя пользователя, объединения групп и тому подобно. В некоторых случаях — в частности, при работе с большими и сложными конфигурациями, — различные параметры можно выносить в отдельные файлы и каталоги.
Более подробно о файле hosts и правилах его написания можно почитать в официальной документации.
Перед внесением изменений Ansible подключается к управляемым узлам и собирает информацию о них: о сетевых интерфейсах и их состоянии, об установленной операционной системе и тому подобное. Он может делать это как с помощью собственного модуля, так и с помощью инструментов ohai и facter, если они установлены (такая возможность специально предусмотрена для пользователей, уже имеющих опыт работы с системами удаленного управления конфигурациями: ohai и facter являются библиотеками фактов для Chef и Puppet).
14. Переменные.
Во время работы, как правило, требуется не только установить какое-либо приложение, но и настроить его в соответствии с определенными параметрами на основании принадлежности к группе серверов или индивидуально (например, IP-адресBGP-соседа и номер его AS или параметры для базы данных).
Как уже было сказано, загромождать файл hosts будет не очень красиво, поэтому разработчики Ansible пошли следующим путём:
файлы с переменными групп хранятся в каталоге ../group_vars/имя_группы;
файлы с переменными хостов в каталоге ../hosts_vars/имя_хоста;
файлы с переменными роли (о них речь пойдет ниже) в директории ../имя_роли/vars/имя_задачи.yml.
Помимо пользовательских переменных можно и даже нужно использовать факты, собранные Ansible перед выполнением сценариев и отдельных задач.
15. Модули Ansible.
В состав Ansible входит огромное количество модулей для развёртывания, контроля и управления различными компонентами, которые можно условно разделить на следующие группы (в скобках приведены названия некоторых продуктов и сервисов):
облачные ресурсы и виртуализация (Openstack, libvirt);
базы данных (MySQL, Postgresql, Redis, Riak);
файлы (шаблонизация, регулярные выражения, права доступа);
мониторинг (Nagios, monit);
оповещения о ходе выполнения сценария (Jabber, Irc, почта, MQTT, Hipchat);
сеть и сетевая инфраструктура (Openstack, Arista);
управление пакетами (apt, yum, rhn-channel, npm, pacman, pip, gem);
система (LVM, Selinux, ZFS, cron, файловые системы, сервисы, модули ядра);
работа с различными утилитами (git, hg).
О том, с чем умеет работать Ansible, можно прочитать в официальной документации. Список действительно впечатляет.
test_servers — это группа серверов, в которую добавлены три сервера с IP-адресами192.168.0.30, 192.168.0.31 и 192.168.0.39;
server 1-3 — это индивидуальные алиасы каждого из серверов группыtest_servers в списке инвентаря;
ansible_ssh_host — это специальная переменная, которая содержит IP-адрес узла, к которому будет создаваться соединение;
ansible_ssh_user — это еще одна специальная переменная которая говорит Ansible‘у подключаться под указанным аккаунтом, то есть пользователем. По умолчанию Ansible использует ваш текущий аккаунт пользователя, или другое значение по умолчанию, указанное в ~/.ansible.cfg (remote_user).
Все сервера, в данном примере, имеют одинаковую операционную систему CentOS Linux release 7.9.2009 (Core), одинаковых пользователей root и одинаковые пароли на учетных записях root.
Открываем конфигурационный файл Ansible (выше по тексту был способ изменить место хранения файла конфигурации):
# mcedit /etc/ansible/ansible.cfg
Снимаем комментарий с опции host_key_checking, приведя ее к виду:
host_key_checking = False
Данная настройка позволит нашему серверу управления автоматически принимать ssh fingerprint, избавляя нас от необходимости постоянно вводить yes, когда мы впервые конфигурируем новый сервер.
Теперь выполним проверку доступности добавленных серверов:
# ansible -m ping test_servers -u root -kK
Данная команда проверит доступность по сети двух серверов из группы test_servers от учетной записи root.
Будет запрошен пароль от учетной записи (в нашем случае, root).
После будет запрошен пароль суперпользователя на серверах.
16.1. Если всё заработало.
На экране должно появиться, примерно, следующее:
Наш сервер управления готов к работе.
16.2. Если не заработало.
Если на экране появится ошибка, введите с сервера Ansible следующую команду:
# ssh root@192.168.0.39
В данном случае, мы пытаемся подключиться к серверу 192.168.0.39 по SSH от пользователя root.
Если подключиться к серверу 192.168.0.39 вышеописанной командой не удалось, возможно введен неправильный пароль или доступ по SSH от root запрещен. В этом случае, создайте служебную учетную запись на сервере 192.168.0.39 и используйте ее для подключения по SSH.
Например, на удаленном сервере вводим:
# useradd ansible-user
# passwd ansible-user
В этом примере мы создали учетную запись ansible-user и задали ей пароль.
Внимание! Обратите внимание, что мы выполняем теперь запрос от пользователя ansible-user.
17. Организация RSA-ключей между серверами.
Для того, что бы Ansible хозяйничал на хостах, требуется включить на целевых для управления хостах разрешение пользоваться аутентификацией по ключам, создать пару RSA-ключей на Ansible Control Machine и копировать открытые ключи на целевые сервера, которыми планируется управлять.
Чтобы убедиться, что Ansible может подключаться к узлам и запускать команды и плейбуки, вы можете использовать следующую команду:
# ansible all -m 'ping'
или, встроенной в Ansible, одноименной утилитой:
# ansible all -m ping
Модуль ping проверит, есть ли у вас учетные данные для подключения к узлам, определенным в файле инвентаря, и может ли Ansible запускать сценарии Python на удаленном сервере от имени root пользователя.
Ответ pong означает, что Ansible готов запускать команды и плейбуки на этом узле.
Ответ:
Проверять с целевыми узлами можно и поштучно через их алиасы:
Если ваши плейбуки Ansible содержат конфиденциальные данные, такие как пароли, ключи API и учетные данные, важно обеспечить их безопасность с помощью шифрования. Ansible предоставляет ansible-vault для шифрования файлов и переменных.
Несмотря на то, что любой файл данных Ansible, а также двоичные файлы, возможно зашифровать изначально, чаще для шифрования переменных файлов, содержащих конфиденциальные данные, используется ansible-vault. После шифрования файла с помощью этого инструмента вы сможете выполнять, редактировать или просматривать его, только предоставив соответствующий пароль, указанный при первом шифровании файла.
Файл инвентаря по умолчанию обычно находится в /etc/ansible/hosts, но вы можете использовать опцию -i для указания пользовательских файлов при запуске команд и плейбуковAnsible.
Это удобный способ настройки индивидуального инвентаря для каждого проекта, который можно включить в системы контроля версий, такие как Git:
Ansible поддерживает сценарии инвентаризации для создания динамических файлов. Это полезно, если ваш инвентарь часто меняется, когда серверы создаются и уничтожаются.
Вы можете найти ряд скриптов с открытым исходным кодом в официальном репозитории Ansible GitHub. После загрузки требуемого сценария на Ansible Control Machine и настройки необходимых параметров (например, учетных данных API) вы можете запустить исполняемый файл в качестве пользовательского инвентаря с любой командой Ansible, которая поддерживает эту опцию.
Следующая команда использует скрипт инвентаря my_inventory.py с командой ping для проверки подключения ко всем текущим активным серверам:
# ansible all -m ping -i my_inventory.py
За более подробной информацией о том, как использовать динамические файлы инвентаризации, пожалуйста, обратитесь к официальной документации Ansible.
Если вы сталкиваетесь с ошибками при выполнении команд и плейбуков, рекомендуется увеличить детализацию вывода, чтобы получить больше информации о проблеме.
Вы можете сделать это, включив в команду параметр -v:
# ansible-playbook myplaybook.yml -v
Если вам нужно больше деталей, вы можете использовать -vvv, и это увеличит детализацию вывода.
Если вы не можете подключиться к удаленным нодам через Ansible, используйте -vvvv для получения информации об отладке соединения:
# ansible-playbook myplaybook.yml -vvvv
24. Возможные ошибки.
24.1. Ошибка «[WARNING]: Updating cache and auto-installing missing dependency: python-apt».
Данная ошибка возникает во время попытки установит пакет с программным обеспечением на целевые хосты с CentOS 7:
# ansible server1 -m apt -a "name=vim"
Ответ с ошибкой:
Устранение ошибки: воспользуйтесь установщиком yum c CentOS 7 совместимых операционных систем, а не apt с Debian совместимых систем.
# ansible server1 -m yum -a "name=vim"
Вариант ответа без ошибки:
Программное обеспечение успешно установилось.
25. Оригиналы источников информации.
selectel.ru «Система управления конфигурацией Ansible».
dmosk.ru «Инструкция по установке и запуску Ansible на CentOS».
Решил написать несколько статей о установке, настройке и роботе с mysql базой данных. В качестве mysql-сервера будем использовать Percona Server 5.6 под управлением операционной системой Ubuntu 12.04. Данная серия статей будет полезной для людей, которые впервые сталкиваются с базами данных(БД) mysql, и хотят немного изучить установку, базовые команды(запросы), научиться делать backup и restore данных, настройку и тестирование репликации БД percona mysql. В этой части пойдет речь о базовой установке и добавлении тестовой БД, репликация которой будет настроена далее.
Поскольку статьи будут взаимосвязаны, наведем схему репликации (рис. 1) и базовую конфигурацию серверов.
Роль хоста
Имя хоста (hostname)
IP хоста
Master server 1
m-serv1
192.168.1.201
Master server 2
m-serv2
192.168.1.202
Slave server 1
m-slave1
192.168.1.203
Slave server 2
m-slave2
192.168.1.204
Рисунок 1 — Схема репликации
1 Установка
Для начала нам нужно установить Percona Server 5.6. Mysql нужно установить на всех серверах, в нашем случаи на 4-х (2 мастера, 2 слейва). Начинаем установку.
root@m-serv1:~# apt-key adv --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /tmp/tmp.igWqa1jBp0 --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
gpg: requesting key CD2EFD2A from hkp server keys.gnupg.net
gpg: key CD2EFD2A: public key "Percona MySQL Development Team <mysql-dev@percona.com>" imported
gpg: Total number processed: 1
gpg: imported: 1
root@m-serv1:~# cat >> /etc/apt/sources.list.d/percona-mysql.list
deb http://repo.percona.com/apt precise main
deb-src http://repo.percona.com/apt precise main
root@m-serv1:~# apt-get update
root@m-serv1:~# apt-get install percona-server-server
При установке, у Вас спросят пароль root-a, который будет использоваться для подключения к mysql серверу – не забудьте его. Далее можно запустить mysql_secure_installation для обновления пароля, удаления ненужных БД и пользователей.
root@m-serv1:~# mysql_secure_installation
Enter current password for root (enter for none):
OK, successfully used password, moving on...
You already have a root password set, so you can safely answer 'n'.
Change the root password? [Y/n] Y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!
Remove anonymous users? [Y/n] Y
... Success!
Disallow root login remotely? [Y/n] Y
... Success!
Remove test database and access to it? [Y/n] Y
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!
Reload privilege tables now? [Y/n] Y
... Success!
Все эти действия нужно проделать на m-serv2, m-slave1 и m-slave2. Теперь можно создать тестовую БД.
2 Добавление данных
2.1 Создание тестовой БД
Можно создать БД (testdb) на одном сервере, сделать ее дамп и развернуть на всех остальных. Что мы и сделаем. Подключаемся на m-serv1 к mysql консоли и создаем тестовую БД.
root@m-serv1:~# mysql -u root -p
mysql> CREATE DATABASE testdb;
Далее добавим таблицу в новую БД.
mysql> CREATE TABLE IF NOT EXISTS testdb.users (id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(20));
Теперь добавим одну строку в таблицу users.
mysql> INSERT INTO users(name) VALUES ("Alex");
Далее проверим что у нас получилось.
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| testdb |
+--------------------+
5 rows in set (0.02 sec)
mysql> use testdb; show tables;
Database changed
+------------------+
| Tables_in_testdb |
+------------------+
| users |
+------------------+
1 row in set (0.00 sec)
mysql> use testdb; select * from users;
Database changed
+----+------+
| id | name |
+----+------+
| 1 | Alex |
+----+------+
1 row in set (0.00 sec)
mysql> use testdb; describe users;
Database changed
+-------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| name | varchar(20) | YES | | NULL | |
+-------+------------------+------+-----+---------+----------------+
2 rows in set (0.03 sec)
Как видим, мы успешно создали БД testdb и в ней создали таблицу users, в которую добавили новую запись.
2.2 Дамп и деплой БД на всех серверах
Снимаем дамп нашей новой БД и копируем его на второй мастер m-serv2.
Теперь логинимся на второй сервер и разворачиваем дамп.
root@m-serv2:~# mysql -u root -p -e 'create database testdb;'
root@m-serv2:~# mysql -uroot -p testdb < testdb.sql
root@m-serv2:~# mysql -u root -p -e 'use testdb; select * from users;'
+----+------+
| id | name |
+----+------+
| 1 | Alex |
+----+------+
Те же действия нужно проделать со слейвами(m-slave1 и m-slave2), т.е. синкануть БД на оба слейва и развернуть таким же макаром.
2.3 Создание юзера для репликации
Теперь нужно создать юзера, который будет заниматься репликацией. Для этого переходим в mysql консоль и создаем юзера replica с правами “replication slave”.
mysql> CREATE USER 'replica'@'%' IDENTIFIED BY '%repl2015';
Query OK, 0 rows affected (0.22 sec)
mysql> GRANT replication slave ON *.* TO 'replica'@'%';
Query OK, 0 rows affected (0.10 sec)
Как вы поняли, эти действия нужно проделать на всех 4-х серверах.
3 Настройка репликации
В mysql существует два типа репликации данных:
Master-Slave
Master-Master
Master-Slave репликация. На Master сервере данные добавляются, удаляются и изменяются. Slave сервер стягивает эти обновления себе и постепенно выполняет все полученные запросы. Если на Slave сервере будет добавлена новая таблица или БД, то данные не попадут на Master. При Master-Master репликации данные попавшие на оба сервера будут среплицированы между собой.
3.1 Master-Master репликация
Сначала настроим Мастер-Мастер репликацию (рис. 2).
Рисунок 2 — Схема Master-Master репликации
Теперь переходим к настройке репликации. Для этого нам нужно добавить конфигурационный файл /etc/mysql/my.cnf для каждого mysql-сервера, который входит в репликацию. Здесь нужно прописать уникальный идентификатор сервера и БД, которые нужно и не нужно реплицировать. Также здесь прописывается множество дополнительных настроек mysql сервера, о которых можно узнать на официальном сайте. Я же наведу самую нужную малость.
3.1.1 Настройка m-serv1 мастера
Сначала настроим первый мастер-сервер.
root@m-serv1:~# cat /etc/mysql/my.cnf
[mysqld]
#Уникальный идентификатор сервера
server-id = 1
#Логи ошибок
log_error = /var/log/mysql/mysql.err
#Путь к bin-логам сервера(бинлог, который ведет мастер)
log-bin = /var/lib/mysql/server-mysql-bin
log-bin-index = /var/lib/mysql/server-mysql-bin.index
#Путь к relay-логам слейва (бинлог, скачанный с мастера)
relay-log = /var/lib/mysql/slave-mysql-relay-bin
relay-log-index = /var/lib/mysql/slave-mysql-relay-bin.index
#БД, которые нужно/не нужно реплицировать
replicate-do-db = testdb
replicate-ignore-db=information_schema
replicate-ignore-db=mysql
replicate-ignore-db=performance_schema
#Не вести журнал бин-лога для БД
binlog-ignore-db = information_schema
binlog-ignore-db = mysql
binlog-ignore-db = performance_schema
#Чтобы не было конфликтов автоинкремента, говорим серверу,
#чтобы id генерировались начиная с 3-го прибавляя по 10,
# например 13, 23, 33, 43...
auto_increment_increment = 10
auto_increment_offset = 3
#Сохранять логи с мастера в своий бин-лог, чтобы передать слейву
log-slave-updates
Как видим, здесь мы добавили для репликации только testdb БД. Теперь рестартуем mysql.
root@m-serv1:~# /etc/init.d/mysql restart
* Stopping MySQL (Percona Server) mysqld [ OK ]
* Starting MySQL (Percona Server) database server mysqld [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
3.1.2 Настройка m-serv2 мастера
Настройка второго мастера аналогична первому, только меняется id и offset
root@m-serv2:~# cat /etc/mysql/my.cnf
[mysqld]
#Уникальный идентификатор сервера
server-id = 2
#Логи ошибок
log_error = /var/log/mysql/mysql.err
#Путь к bin-логам сервера(бинлог, который ведет мастер)
log-bin = /var/lib/mysql/server-mysql-bin
log-bin-index = /var/lib/mysql/server-mysql-bin.index
#Путь к relay-логам слейва (бинлог, скачанный с мастера)
relay-log = /var/lib/mysql/slave-mysql-relay-bin
relay-log-index = /var/lib/mysql/slave-mysql-relay-bin.index
#БД, которые нужно/не нужно реплицировать
replicate-do-db = testdb
replicate-ignore-db=information_schema
replicate-ignore-db=mysql
replicate-ignore-db=performance_schema
#Не вести журнал бин-лога для БД
binlog-ignore-db = information_schema
binlog-ignore-db = mysql
binlog-ignore-db = performance_schema
#Чтобы не было конфликтов автоинкремента, говорим серверу,
#чтобы id генерировались начиная с 4-го прибавляя по 10,
# например 14, 24, 34, 44...
auto_increment_increment = 10
auto_increment_offset = 4
#Сохранять логи с мастера в своий бин-лог, чтобы передать слейву
log-slave-updates
Рестартуем mysql.
root@m-serv2:~# /etc/init.d/mysql restart
* Stopping MySQL (Percona Server) mysqld [ OK ]
* Starting MySQL (Percona Server) database server mysqld [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
3.1.3 Запуск репликации
Сначала запустим репликацию на первом мастере m-serv1. Для этого нам нужно знать MASTER_LOG_FILE и MASTER_LOG_POSm-serv2 сервера, т.е. нашего второго мастера. Логинимся на m-serv2 и смотрим master status.
Все интуитивно понятно. Теперь стартуем слейв и смотрим статус.
root@m-serv1:~# mysql -u root -p -e 'start slave;'
root@m-serv1:~# mysql -u root -p -e 'show slave status G;'
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.202
Master_User: replica
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: server-mysql-bin.000001
Read_Master_Log_Pos: 120
Relay_Log_File: slave-mysql-relay-bin.000002
Relay_Log_Pos: 290
Relay_Master_Log_File: server-mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: testdb
Replicate_Ignore_DB: information_schema,mysql,performance_schema
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 120
Relay_Log_Space: 469
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2
Master_UUID: 25f9f3ac-fd3b-11e4-bb77-080027ead940
Master_Info_File: /var/lib/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Со всего этого вывода нас интересуют Seconds_Behind_Master (время отставания реплики от мастера), Slave_IO_State (должно писать, что ждет новостей от мастера), Slave_IO_Running (Yes) и Slave_SQL_Running (Yes). Если репликация идет нормально, реплика будет следовать за мастером (номер лога в Master_Log_File и позиция Exec_Master_Log_Pos будут расти). Отставания реплики от мастера (Seconds_Behind_Master), должно быть нулевым, но может расти. Если же значение Slave_IO_State пусто, а Seconds_Behind_Master равно NULL, репликация не началась. У нас все гуд. Поэтому узнаем master статус на m-serv1 и беремся за m-serv2.
Все прошло успешно. О парочке возможных ошибок и их исправлении будет написано в следующей статье.
3.1.4 Тестируем репликацию
Теперь можно немножко и протестировать. Перейдем на m-serv1 и добавим в testdb.users новую строку.
root@m-serv1:~# mysql -u root -p -e 'USE testdb; INSERT INTO users(name) VALUES ("Vova");'
root@m-serv1:~# mysql -u root -p -e 'USE testdb; SELECT * FROM users;'
+----+------+
| id | name |
+----+------+
| 1 | Alex |
| 3 | Vova |
+----+------+
Теперь проверим среплицировалась ли запись на второй сервер.
root@m-serv2:~# mysql -u root -p -e 'USE testdb;SELECT * FROM users;'
+----+------+
| id | name |
+----+------+
| 1 | Alex |
| 3 | Vova |
+----+------+
Все в порядке, запись попала на второй сервер. Теперь добавим запись на втором сервере и посмотрим попадет ли она на первый мастер.
root@m-serv2:~# mysql -u root -p -e 'USE testdb; INSERT INTO users(name) VALUES ("Pasha");'
root@m-serv2:~# mysql -u root -p -e 'USE testdb; SELECT * FROM users;'
+----+-------+
| id | name |
+----+-------+
| 1 | Alex |
| 3 | Vova |
| 4 | Pasha |
+----+-------+
Смотрим на первом мастере.
root@m-serv1:~# mysql -u root -p -e 'USE testdb; SELECT * FROM users;'
+----+-------+
| id | name |
+----+-------+
| 1 | Alex |
| 3 | Vova |
| 4 | Pasha |
+----+-------+
Как видим, все ок. Добавим еще по одной записи.
root@m-serv1:~# mysql -u root -p -e 'USE testdb;INSERT INTO users(name) VALUES ("Frodo");'
root@m-serv1:~# mysql -u root -p -e 'USE testdb; SELECT * FROM users;'
+----+-------+
| id | name |
+----+-------+
| 1 | Alex |
| 3 | Vova |
| 4 | Pasha |
| 13 | Frodo |
+----+-------+
root@m-serv2:~# mysql -u root -p -e 'USE testdb; INSERT INTO users(name) VALUES ("Misha");'
root@m-serv2:~# mysql -u root -p -e 'USE testdb; SELECT * FROM users;'
+----+-------+
| id | name |
+----+-------+
| 1 | Alex |
| 3 | Vova |
| 4 | Pasha |
| 13 | Frodo |
| 14 | Misha |
+----+-------+
Как видим, если запись добавлена с сервера m-serv1, то поле auto_increment(id) имеет значения 3, 13, а при добавлении записей с m-serv2, эти значения равны 4, 14. Это нужно чтобы избежать ошибок типа Duplicate entry.
Продолжим знакомство с Percona mysql репликацией и перейдем к настройке и тестированию Master-Slave репликации. Как и в предыдущих статьях, наведу рисунок нашей схемы репликации, которую мы затеяли (рис. 3).
Рисунок 3 — Схема Master-Slave репликации
3.2 Master-Slave репликация
Мастер-Мастер репликация была настроена, теперь можно добавлять слейвы (рис. 3). Для этого нам нужно добавить конфигурационный файл /etc/mysql/my.cnf для каждого mysql-слейва, который входит в репликацию.
3.2.1 Настройка m-slave1 слейва
Сначала настроим первый слейв-сервер.
root@m-slave1:~# cat /etc/mysql/my.cnf
[mysqld]
#Уникальный идентификатор сервера
server-id = 3
#Логи ошибок
log_error = /var/log/mysql/mysql.err
#Путь к relay-логам слейва (бинлог, скачанный с мастера)
relay-log = /var/lib/mysql/slave-mysql-relay-bin
relay-log-index = /var/lib/mysql/slave-mysql-relay-bin.index
#БД, которые нужно/не нужно реплицировать
replicate-do-db = testdb
replicate-ignore-db=information_schema
replicate-ignore-db=mysql
replicate-ignore-db=performance_schema
#Чтобы не было конфликтов автоинкремента, говорим серверу,
#чтобы id генерировались начиная с 4-го прибавляя по 10,
# например 11, 21, 31, 41...
auto_increment_increment = 10
auto_increment_offset = 1
Теперь рестартуем mysql
root@m-slave1:~# /etc/init.d/mysql restart
* Stopping MySQL (Percona Server) mysqld [ OK ]
* Starting MySQL (Percona Server) database server mysqld [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
3.2.2 Настройка m-slave2 слейва
Переходим к настройке второго слейва.
root@m-slave2:~# cat /etc/mysql/my.cnf
[mysqld]
#Уникальный идентификатор сервера
server-id = 4
#Логи ошибок
log_error = /var/log/mysql/mysql.err
#Путь к relay-логам слейва (бинлог, скачанный с мастера)
relay-log = /var/lib/mysql/slave-mysql-relay-bin
relay-log-index = /var/lib/mysql/slave-mysql-relay-bin.index
#БД, которые нужно/не нужно реплицировать
replicate-do-db = testdb
replicate-ignore-db=information_schema
replicate-ignore-db=mysql
replicate-ignore-db=performance_schema
#Чтобы не было конфликтов автоинкремента, говорим серверу,
#чтобы id генерировались начиная с 4-го прибавляя по 10,
# например 12, 22, 32, 42...
auto_increment_increment = 10
auto_increment_offset = 2
Теперь рестартуем mysql
root@m-slave2:~# /etc/init.d/mysql restart
* Stopping MySQL (Percona Server) mysqld [ OK ]
* Starting MySQL (Percona Server) database server mysqld [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
3.2.3 Запуск репликации
Если вы следовали пункту 3.1.4 (Тестирование мастер репликации) после настройки Мастер – Мастер репликации, то на обоих слейвах нужно разворачивать новый дамп testdb, так как в эту БД добавлялись данные. Т.е. для слейва m-slave1 нужно снять дамп с мастера m-serv1 и развернуть (описано в пункте 2.2 Дамп и деплой), для m-slave2 дамп нужно снять с m-serv2 и развернуть. После того, как дамп будет развернут, у нас будут следующие данные в БД testdb.
root@m-slave1:~# mysql -u root -p -e 'use testdb;select * from users;'
Enter password:
+----+-------+
| id | name |
+----+-------+
| 1 | Alex |
| 3 | Vova |
| 4 | Pasha |
| 13 | Frodo |
| 14 | Misha |
+----+-------+
Т.е. те же данные, что остались на мастер-серверах после тестирования Масте-Мастер репликации. Теперь осталось запустить репилкацию. В случаи с m-slave1 мастер сервер должен быть m-serv1, поэтому переходим на первый мастер сервер и смотрим MASTER_LOG_FILE и MASTER_LOG_POS.
Все интуитивно понятно. Теперь стартуем слейв и смотрим статус.
root@m-slave2:~# mysql -u root -p -e 'start slave;'
root@m-slave2:~# mysql -u root -p -e 'show slave status G;'
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.202
Master_User: replica
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: server-mysql-bin.000002
Read_Master_Log_Pos: 120
Relay_Log_File: slave-mysql-relay-bin.000002
Relay_Log_Pos: 290
Relay_Master_Log_File: server-mysql-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: testdb
Replicate_Ignore_DB: information_schema,mysql,performance_schema
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 120
Relay_Log_Space: 469
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2
Master_UUID: 25f9f3ac-fd3b-11e4-bb77-080027ead940
Master_Info_File: /var/lib/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
3.2.4 Тестируем репликацию
Тестируем всю нашу цепочку репликации (рис. 1). Перейдем на первый мастер сервер и добавим новую запись в testdb.users.
root@m-serv1:~# mysql -u root -p -e 'USE testdb; INSERT INTO users(name) VALUES ("Server1 record");'
root@m-serv1:~# mysql -u root -p -e 'select * from testdb.users;'
+----+----------------+
| id | name |
+----+----------------+
| 1 | Alex |
| 3 | Vova |
| 4 | Pasha |
| 13 | Frodo |
| 14 | Misha |
| 23 | Server1 record |
+----+----------------+
Теперь проверяем добавилась ли запись на все слейвы и на второй мастер
root@m-slave1:~# mysql -u root -p -e 'use testdb;select * from users;'
+----+----------------+
| id | name |
+----+----------------+
| 1 | Alex |
| 3 | Vova |
| 4 | Pasha |
| 13 | Frodo |
| 14 | Misha |
| 23 | Server1 record |
+----+----------------+
root@m-slave2:~# mysql -u root -p -e 'use testdb;select * from users;'
+----+----------------+
| id | name |
+----+----------------+
| 1 | Alex |
| 3 | Vova |
| 4 | Pasha |
| 13 | Frodo |
| 14 | Misha |
| 23 | Server1 record |
+----+----------------+
root@m-serv2:~# mysql -u root -p -e 'use testdb;select * from users;'
+----+----------------+
| id | name |
+----+----------------+
| 1 | Alex |
| 3 | Vova |
| 4 | Pasha |
| 13 | Frodo |
| 14 | Misha |
| 23 | Server1 record |
+----+----------------+
Как видим, все в порядке. Теперь добавим запись на втором мастере.
root@m-serv2:~# mysql -u root -p -e 'USE testdb; INSERT INTO users(name) VALUES ("Server2 record");'
root@m-serv2:~# mysql -u root -p -e 'select * from testdb.users;'
+----+----------------+
| id | name |
+----+----------------+
| 1 | Alex |
| 3 | Vova |
| 4 | Pasha |
| 13 | Frodo |
| 14 | Misha |
| 23 | Server1 record |
| 24 | Server2 record |
+----+----------------+
Теперь проверяем добавилась ли запись на все слейвы и на первый мастер
root@m-slave1:~# mysql -u root -p -e 'use testdb;select * from users;'
+----+----------------+
| id | name |
+----+----------------+
| 1 | Alex |
| 3 | Vova |
| 4 | Pasha |
| 13 | Frodo |
| 14 | Misha |
| 23 | Server1 record |
| 24 | Server2 record |
+----+----------------+
root@m-slave2:~# mysql -u root -p -e 'use testdb;select * from users;'
+----+----------------+
| id | name |
+----+----------------+
| 1 | Alex |
| 3 | Vova |
| 4 | Pasha |
| 13 | Frodo |
| 14 | Misha |
| 23 | Server1 record |
| 24 | Server2 record |
+----+----------------+
root@m-serv1:~# mysql -u root -p -e 'use testdb;select * from users;'
+----+----------------+
| id | name |
+----+----------------+
| 1 | Alex |
| 3 | Vova |
| 4 | Pasha |
| 13 | Frodo |
| 14 | Misha |
| 23 | Server1 record |
| 24 | Server2 record |
+----+----------------+
Как видим, репликация работает как и предполагалось.
4. Распространенные ошибки
========================================================================== Ошибка: ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository Решение:
Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND for deleting row
Can’t drop database ‘********’: database doesn’t exist’
Error ‘Duplicate entry’
Could not execute Write_rows event on table ***********: Duplicate entry ‘XXXXXXXX’ for key ‘ххххххх’, Error_code: 1062
Решение: Эти ошибки можно просто скипнуть, но посмотреть их причины сначала.
mysql -uroot -p -e 'STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE;'
========================================================================== Ошибка: Relay log read failure (#1594): Could not parse relay log event entry. Решение:
#Подключаемся к серверу, где возникла проблема и смотрим статус репликации
root@server:~# mysql -uroot -p -e 'show slave status G;' | grep -E 'Relay_Master_Log_File|Exec_Master_Log_Pos'
Relay_Master_Log_File: mysql-bin.008189
Exec_Master_Log_Pos: 71687831
# Останавливаем репликацию и обновляем бин-лог и позицию
#master_log_file = Relay_Master_Log_File = mysql-bin.008189
#master_log_pos = Exec_Master_Log_Pos = 71687831
root@server:~# mysql -uroot -p -e "STOP SLAVE;"
root@server:~# mysql -uroot -p -e "CHANGE MASTER TO master_log_file='mysql-bin.008189', master_log_pos=71687831;"
#Стартуем слейв
root@server:~# mysql -uroot -p218e5ccb4a834382%FBF87B604F1FE14B -e "START SLAVE;"
mysqladmin -u root -p'old_pass' password 'new_pass'
или
mysql> use mysql;
mysql> update user set password=PASSWORD("newpass") where User='ENTER-USER-NAME-HERE';
mysql> create user 'user1'@'localhost' identified by 'user1pass';
Добавить все права на все базы и все таблицы.
#GRANT [тип прав] ON [название БД].[название таблицы] TO '[имя пользователя]'@'localhost';
mysql> grant ALL PRIVILEGES ON *.* to 'user1'@'localhost';
mysql> flush privileges;
Удаление прав для пользователя.
#REVOKE [тип прав] ON [название БД].[название таблицы] FROM '[имя пользователя]'@'localhost';
mysql> revoke ALL on *.* from 'user1'@'localhost';
Удалить пользователя.
mysql> drop user 'user1'@'localhost';
5.4.1 Сброс пароля root, если забыли.
1. Остановка сервера
# /etc/init.d/mysql stop
2. Запуск mysql со скипом привилегий
mysqld --skip-grant-tables --user=mysql &
или
mysqld_safe --skip-grant-tables &
3. Логинимся в БД без пароля. Пароль хэшируется с помощью функции PASSWORD(str). Это специальная функция, которая возвращает строку 16-byte и используется системой аутентификации исключительно mysql сервером. Поэтому, используйте MD5 или SHA1 для хранения паролей приложений, которые юзают mysql, но не PASSWORD.
6. Теперь останавливаем mysqld, который запускали вручную и запускаем init-скрипт.
kill `pgrep mysql`
/etc/init.d/mysql start
* Starting MySQL (Percona Server) database server mysqld
Установка и настройка Percona XtraDB Cluster
Поднять mysql кластер можно в несколько раз быстрее используя такую вещь, как Percona XtraDB Cluster, о чем и пойдет речь в данной статье.
Создадим Percona XtraDB Cluster с трех серверов под управлением операционной системы Ubuntu 12.04. Установка будет произведена из репозитория. Для начала, логинимся на первый сервер, добавляем ключик и репозитории.
root@pxc1:~#apt-key adv --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
root@pxc1:~#vim /etc/apt/sources.list.d/pxe.list
…
deb http://repo.percona.com/apt precise main
deb-src http://repo.percona.com/apt precise main
...
root@pxc1:~#apt-get update
Теперь ставим непосредственно Percona XtraDB Cluster пакет.
Во время установки нужно будет ввести пароль для доступа к mysql БД. Перед добавлением ноды в кластер, нужно стопнуть mysql.
root@pxc1:~#/etc/init.d/mysql stop
Добавляем главный конфигурационных файл для первого mysql PXC1 сервера.
root@pxc1:~#cat /etc/mysql/my.cnf
…
[mysqld]
# Логи
log_error = /var/log/mysql/mysql.err
# Директория с БД
datadir=/var/lib/mysql
# Пользователь
user=mysql
# Путь к Galera модуля
wsrep_provider=/usr/lib/libgalera_smm.so
# URL с IP адресами серверов, которые входят в кластер
wsrep_cluster_address=gcomm://192.168.1.150,192.168.1.151,192.168.1.152
# Формат бинлогов
binlog_format=ROW
# Дефолтный механизм хранения данных
default_storage_engine=InnoDB
# Режим лока при работе с автоинкремент значениями
innodb_autoinc_lock_mode=2
# Адрес первой ноды в кластере
wsrep_node_address=192.168.1.150
# Метод передачи снепшотов БД
wsrep_sst_method=xtrabackup-v2
# Имя кластера
wsrep_cluster_name=test_mysql_cluster
# Аутентификация для SST
wsrep_sst_auth="sstuser:DOGUQpj0Se8Q9oy7"
…
Теперь можно стартовать mysql сервер в режиме bootstrap.
root@pxc1:~#/etc/init.d/mysql bootstrap-pxc
После этого у нас добавиться первая нода в кластер. Для проверки, можно запустить команду.
root@pxc1:~# mysql -u root -p -e "show status like 'wsrep%';" | grep -E 'local_state|cluster|ready|connected'
wsrep_local_state_uuid b2cf979d-54ca-11e5-9bb4-628c43a251a6
wsrep_local_state 4
wsrep_local_state_comment Synced
wsrep_cluster_conf_id 1
wsrep_cluster_size 1
wsrep_cluster_state_uuid b2cf979d-54ca-11e5-9bb4-628c43a251a6
wsrep_cluster_status Primary
wsrep_connected ON
wsrep_ready ON
Этот вывод означает, что все ок. Теперь нужно добавить юзера с привилегиями для SST операций, которого мы добавили в конце my.cnf файла.
root@pxc1:~# mysql -u root -p
mysql> CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'DOGUQpj0Se8Q9oy7';
Query OK, 0 rows affected (1.27 sec)
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost';
Query OK, 0 rows affected (0.62 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.48 sec)
Далее переходим к настройке второго сервера. Устанавливаем mysql Percona XtraDB Cluster таким же образом и переходим к редактированию my.cnf файла.
root@pxc2:~#cat /etc/mysql/my.cnf
…
[mysqld]
# Логи
log_error = /var/log/mysql/mysql.err
# Директория с БД
datadir=/var/lib/mysql
# Пользователь
user=mysql
# Путь к Galera модуля
wsrep_provider=/usr/lib/libgalera_smm.so
# URL с IP адресами серверов, которые входят в кластер
wsrep_cluster_address=gcomm://192.168.1.150,192.168.1.151,192.168.1.152
# Формат бинлогов
binlog_format=ROW
# Дефолтный механизм хранения данных
default_storage_engine=InnoDB
# Режим лока при работе с автоинкремент значениями
innodb_autoinc_lock_mode=2
# Адрес первой ноды в кластере
wsrep_node_address=192.168.1.151
# Метод передачи снепшотов БД
wsrep_sst_method=xtrabackup-v2
# Имя кластера
wsrep_cluster_name=test_mysql_cluster
# Аутентификация для SST
wsrep_sst_auth="sstuser:DOGUQpj0Se8Q9oy7"
…
И стартуем mysql в нормально режиме.
root@pxc2:~#/etc/init.d/mysql start
После этого, второй сервер добавиться в кластер. Проверяем.
root@pxc2:~# mysql -u root -p -e "show status like 'wsrep%';" | grep -E 'local_state|cluster|ready|connected'
wsrep_local_state_uuid b2cf979d-54ca-11e5-9bb4-628c43a251a6
wsrep_local_state 4
wsrep_local_state_comment Synced
wsrep_cluster_conf_id 4
wsrep_cluster_size 2
wsrep_cluster_state_uuid b2cf979d-54ca-11e5-9bb4-628c43a251a6
wsrep_cluster_status Primary
wsrep_connected ON
wsrep_ready ON
Ну и добавляем последнюю ноду. Устанавливаем Percona XtraDB Cluster и создаем my.cnf.
root@pxc3:~#cat /etc/mysql/my.cnf
…
[mysqld]
# Логи
log_error = /var/log/mysql/mysql.err
# Директория с БД
datadir=/var/lib/mysql
# Пользователь
user=mysql
# Путь к Galera модуля
wsrep_provider=/usr/lib/libgalera_smm.so
# URL с IP адресами серверов, которые входят в кластер
wsrep_cluster_address=gcomm://192.168.1.150,192.168.1.151,192.168.1.152
# Формат бинлогов
binlog_format=ROW
# Дефолтный механизм хранения данных
default_storage_engine=InnoDB
# Режим лока при работе с автоинкремент значениями
innodb_autoinc_lock_mode=2
# Адрес первой ноды в кластере
wsrep_node_address=192.168.1.152
# Метод передачи снепшотов БД
wsrep_sst_method=xtrabackup-v2
# Имя кластера
wsrep_cluster_name=test_mysql_cluster
# Аутентификация для SST
wsrep_sst_auth="sstuser:DOGUQpj0Se8Q9oy7"
…
И стартуем mysql.
root@pxc3:~#/etc/init.d/mysql start
Проверяем статус кластера.
root@pxc3:~# mysql -u root -p -e "show status like 'wsrep%';" | grep -E 'local_state|cluster|ready|connected'
wsrep_local_state_uuid b2cf979d-54ca-11e5-9bb4-628c43a251a6
wsrep_local_state 4
wsrep_local_state_comment Synced
wsrep_cluster_conf_id 7
wsrep_cluster_size 3
wsrep_cluster_state_uuid b2cf979d-54ca-11e5-9bb4-628c43a251a6
wsrep_cluster_status Primary
wsrep_connected ON
wsrep_ready ON
Как видим, у нас все 3 ноды успешно добавлены в кластер. Теперь можно протестировать работу. Переходим на первую ноду, создаем тестовую БД, таблицу и добавляем запись в неё.
root@pxc1:~# mysql -u root –p
mysql> CREATE DATABASE firstDB;
Query OK, 1 row affected (0.01 sec)
mysql> USE firstDB;
Database changed
mysql> CREATE TABLE records (rec VARCHAR(50));
Query OK, 0 rows affected (0.08 sec)
mysql> INSERT INTO records VALUE ("pxc1 record");
Query OK, 1 row affected (0.12 sec)
mysql> SELECT * FROM records;
+-------------+
| rec |
+-------------+
| pxc1 record |
+-------------+
1 row in set (0.00 sec)
Теперь идем на второй сервер и проверяем работает ли репликация.
root@pxc2:~# mysql -uroot -p
mysql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| firstDB |
| mysql |
| performance_schema |
| test |
+--------------------+
Как видим, БД среплицировалась. Теперь добавив еще одну запись в таблицу.
mysql> INSERT INTO records VALUE ("pxc2 record");
Query OK, 1 row affected (0.04 sec)
mysql> SELECT * FROM records;
+-------------+
| rec |
+-------------+
| pxc1 record |
| pxc2 record |
+-------------+
2 rows in set (0.00 sec)
Первая запись среплицировалась и теперь у нас есть две записи. Проверяем последний сервер.
root@pxc3:~# mysql -u root -p
mysql> USE firstDB;
Database changed
mysql> SELECT * FROM records;
+-------------+
| rec |
+-------------+
| pxc1 record |
| pxc2 record |
+-------------+
2 rows in set (0.00 sec)
Кластер работает как положено. Для тестов, еще можно выключить одну машину и через некоторое время включить обратно. В этом случаи в кластере будет только две машины, а после включения третей – все данные, которые были добавлены в период колапса будут среплицированы на поднявшуюся ноду.
Я рассказывал в своих заметках о установке, настройке, масштабировании и о джобах в Jenkins-е. В голову пришло еще то, что нужно еще и иметь бэкапы для того, чтобы можно было откатится назад. Я нагуглил пару решений. Но еще не решил какое лучше. По этому, расскажу о них.
И так, нам понадобится установить плагин(ы) (можно и один на выбор, я использовал несколько для сравнения):
Thin backup
Backup Plugin
Periodic Backup
SCM Sync configuration
Можно заюзать и другие решения:
Использовать Git и взять «$JENKINS_HOME» под него.
Написать BASH скрипт и создать джобу на ее выполнение.
Перейдем к решениям!
Использование Thin backup плагина для backup/restore Jenkins-а в Unix/Linux
Переходим «Manage Jenkins» -> «Manage Plugins» и устанавливаем «Thin backup». Я обычно всегда перезапускаю дженкинс для того, чтобы применились все настройки и все работало.
PS: Для перезагрузки дженкинс-сервера, я использую «Restart Safely» плагин.
Настройки бекапа, переходим в «Manage Jenkins» -> «ThinBackup»:
Плагин ThinBackup для Jenkins-а
В данном плагине имеются:
Backup Now — Кнопка чтобы сделать бекап сейчас.
Restore — Служит для рестора данных.
Settings — Настройка для бэкапа.
Начнем с настройки, нажимаем по нему:
Настройка thinBackup плагина для бэкапа дженкинса
Я отметил нужные мне поля и нажал на кнопку «Save». Т. е у меня будут выполнятся бэкапы по заданному расписанию и складыватся в «/backups» папку. Теперь можно запустить «Backup now» чтобы выполнился бэкап.
Вот и все. Можно юзать данный плагин для бэкаа и рестора.
Использование Backup Plugin плагина для backup/restore Jenkins-а в Unix/Linux
Переходим «Manage Jenkins» -> «Manage Plugins» и устанавливаем «Backup plugin». Я обычно всегда перезапускаю дженкинс для того, чтобы применились все настройки и все работало.
Настройки бекапа, переходим в «Manage Jenkins» -> «Backup manager»:
В данном плагине имеются:
Setup — Служит для настройки бэкапов.
Backup Hudson configuration — Чтобы создать бэкап.
Restore Hudson configuration — Для рестора бэкапа.
Я привел настройку к такому виду:
После настроек нажимаем на «Save». Нажимаем на «Backup Hudson configuration» для создания бэкапа.
Использование Periodic Backup плагина для backup/restore Jenkins-а в Unix/Linux
Переходим «Manage Jenkins» -> «Manage Plugins» и устанавливаем «Periodic Backup». Я обычно всегда перезапускаю дженкинс для того, чтобы применились все настройки и все работало.
Настройки бекапа, переходим в «Manage Jenkins» -> «Periodic Backup Manager»:
Меню Periodic Backup plugin
Плагин не сконфигурирован и его нужно отконфигурить. Что я и сделаю сейчас, нажимаем на «Configure»:
Настройка Periodic Backup plugin
Вот и все. Можно выполнить бэкап! Данный плагин понравился больше чем другие!
Использование SCM Sync configuration плагина для backup/restore Jenkins-а в Unix/Linux
Переходим «Manage Jenkins» -> «Manage Plugins» и устанавливаем «SCM Sync configuration». Я обычно всегда перезапускаю дженкинс для того, чтобы применились все настройки и все работало.
Создам проект в гитлабе, например «configurations/jenkins».В данной проекте я буду хранить все настройки.
Переходим в «Manage Jenkins» -> «Configure System» и находим поле «SCM» и заполняем поля. У меня не получилось подружится с этим плагином вообще. Снес его!
Использование bash-скрипта для backup/restore Jenkins-а в Unix/Linux
Можно написать скрипты на любой вкус, используя bash. Есть плагин для запуска скриптов через джобу. Сейчас поставим данный плагин.
Переходим «Manage Jenkins» -> «Manage Plugins» и устанавливаем «Exclusive Execution». Я обычно всегда перезапускаю дженкинс для того, чтобы применились все настройки и все работало. Создам структуру: Projects->Configurations. Т.е папка Projects в ней будут проекты, в данном случае «Configurations» — конфиги (Для создания папки, нажмите «New item» и выбирете «folder»).
Переходим в проект и нажимаем на «New item» и кликаем по «Freestyle project». Вводим имя для проекта, у меня — «jenkins-backup» и нажимаем на «OK»:
Freestyle project для Jenkins бекапа
Потом переходим в созданный проект и нажимаем на «Configure» и находим поле «Source Code Management» и прописываем УРЛ где будет лежать скрипт для бэкапа у меня это готовое решение какого-то чела, например:
настройка SCM
Идем дальше и переходим во «Build Triggers» вкладку и заполним:
Т.е заполним переодичность с которой будет запускаться скрипт.sh1 lines
H 3 * * *
После этого переходим во «Build» вкладку и затем, из списка выбираем «Execute shell». и прописываем параметры для запуска:
Настройка запуска скрипта с параметрами через Build-execute shell
И на этом все, нажимаем на «Save». После этого, будет выполнятся бекап по заданному времени. Если есть необходимость, то можно запустить джобу маннуалли (Нажав на «Build Now»).
PS: Можно сделать бэкап-ротейт чтобы все старые бэкапы удалялись автоматом, например, можно добавить еще один «Execute shell» команду:sh1 lines
find /backups/backup_* -mtime +7 -delete
Т.е бэкапы будут хранится 7 дней, остальные будут удалены.
Вот еще один пример скрипта, который можно использовать:sh42 lines
#!/bin/bash
# Setup
#
# - Create a new Jenkins Job
# - Mark "None" for Source Control Management
# - Select the "Build Periodically" build trigger
# - configure to run as frequently as you like
# - Add a new "Execute Shell" build step
# - Paste the contents of this file as the command
# - Save
#
# NOTE: before this job will work, you'll need to manually navigate to the $JENKINS_HOME directory
# and do the initial set up of the git repository.
# Make sure the appropriate remote is added and the default remote/branch set up.
#
# Jenkins Configuraitons Directory
cd $JENKINS_HOME
# Add general configurations, job configurations, and user content
git add -- *.xml jobs/*/*.xml userContent/*
# only add user configurations if they exist
if [ -d users ]; then
user_configs=`ls users/*/config.xml`
if [ -n "$user_configs" ]; then
git add $user_configs
fi
fi
# mark as deleted anything that's been, well, deleted
to_remove=`git status | grep "deleted" | awk '{print $3}'`
if [ -n "$to_remove" ]; then
git rm --ignore-unmatch $to_remove
fi
git commit -m "Automated Jenkins commit"
git push -q -u origin master
Как по мне, все тут логично и понятно что он делаеет… Аналогичным способом можно сделать джобу и запускать переодически. Тем самым, все конфиг-файлы, будут попадать в гит.
Вывод: Я протестировал несколько плагинов и выбрал — использовать скрипты или Thin backup, Periodic Backup плагины. Но если есть другие решения, — пишите, дополню материал.
Я для клиента писал вот такой скрипт:sh38 lines
#!/usr/bin/env bash
# JENKINS_HOME
# +- config.xml (jenkins root configuration)
# +- *.xml (other site-wide configuration files)
# +- userContent (files in this directory will be served under your http://server/userContent/)
# +- fingerprints (stores fingerprint records)
# +- nodes (slave configurations)
# +- plugins (stores plugins)
# +- secrets (secretes needed when migrating credentials to other servers)
# +- workspace (working directory for the version control system)
# +- [JOBNAME] (sub directory for each job)
# +- jobs
# +- [JOBNAME] (sub directory for each job)
# +- config.xml (job configuration file)
# +- latest (symbolic link to the last successful build)
# +- builds
# +- [BUILD_ID] (for each build)
# +- build.xml (build result summary)
# +- log (log file)
# +- changelog.xml (change log)
echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~";
echo "==================== Jenkins backup ====================";
echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~";
JENKINS_DIR="/mnt/data/jenkins"
JENKINS_BACKUP_DIR="/mnt/data/jenkins_backup"
cp -r ${JENKINS_DIR}/*.xml ${JENKINS_BACKUP_DIR}
cp -r ${JENKINS_DIR}/userContent ${JENKINS_BACKUP_DIR}
cp -r ${JENKINS_DIR}/fingerprints ${JENKINS_BACKUP_DIR}
cp -r ${JENKINS_DIR}/nodes ${JENKINS_BACKUP_DIR}
cp -r ${JENKINS_DIR}/plugins ${JENKINS_BACKUP_DIR}
cp -r ${JENKINS_DIR}/secrets ${JENKINS_BACKUP_DIR}
cp -r ${JENKINS_DIR}/workspace ${JENKINS_BACKUP_DIR}
cp -r ${JENKINS_DIR}/jobs ${JENKINS_BACKUP_DIR}
Проверялось, — работает!
Резервное копирование для Jenkins
Все, кто занимается задачами CI/CD, так или иначе знают про Jenkins, даже если им посчастливилось не иметь с ним дела.
Этот непотопляемый кадавр продолжает жить и процветать по следующим причинам:
гибкость настроек (от настраиваемых диалоговых окон до встроенного Groovy);
архитектура с поддержкой плагинов и обширный набор готовых плагинов на все случаи жизни;
и самое главное — большой накопленный объём пользовательских проектов, которые проще продолжать развивать и поддерживать в среде Дженкинса, чем пытаться мигрировать на более современные и приятные платформы.
Очевидно, что чем важнее данные внутри Дженкинса для тех, кто им пользуется, тем актуальнее для них резервное копирование этих данных.
Однако здесь возникают два небольших препятствия:
настройки, временные данные и файлы проектов смешаны внутри рабочего каталога в одну кучу;
штатного механизма не существует, вместо него есть энное число посторонних костылей, распространяемых в виде плагинов, описаний и копипаст.
Список предварительных пожеланий к нему был примерно таким:
резервная копия должна иметь минимальный размер и максимальную скорость создания (например, дамп виртуальной машины или снимок ZFS с сотнями гигабайт проектов не годится);
после восстановления нам достаточно иметь полностью настроенный сервер без предыдущего состояния — который знает, как выполнять новые job’ы, но ничего не помнящий про старые;
поскольку настройки имеют текстовый вид, пусть они сохраняются в Git-репозиторий;
если Jenkins предназначен для автоматического выполнения заданий, пусть самостоятельно выполняет всю работу по своему обслуживанию.
Общая схема:
в $JENKINS_HOME создаётся Git-репозиторий;
на Git-сервере для него создаётся origin (далее приводятся настройки для Gitlab);
в Дженкинсе создаётся периодическое задание, которое сохраняет в Git ключевые файлы;
для уменьшения размера от плагинов сохраняются только манифесты, при восстановлении плагины скачиваются заново.
Сначала создайте пользователя и репозиторий в Gitlab’e:
пользователь = jenkins-backup-robot;
репозиторий = jenkins-configs;
URL репозитория скопируйте в буфер обмена;
откройте Repository => Settings => Members;
назначьте jenkins-backup-robot мантейнером (иначе Gitlab не даст сделать ему первый push в пустой репозиторий).
Теперь идите в командную строку сервера, на котором работает Jenkins:
Это делается в разделе Admin => Users => jenkins-backup-robot => Impersonate => Personal Settings => SSH keys.
Создайте в Дженкинсе новое задание:
Name: Backup Jenkins configs to Git
Type: Free job
Label: master
SCM: None
Build: Build Periodically
Schedule: 20 04 * * *
Build step: Execute Shell
Command:
#!/bin/sh -e
cd "$JENKINS_HOME"
# Add general configurations, secrets, job configurations, nodes, user content, users and plugins info:
ls -1d *.xml secrets/ jobs/*/*.xml nodes/*/*.xml userContent/* users/*/config.xml
plugins/*/META-INF/MANIFEST.MF 2>/dev/null | grep -v '^queue.xml$' | xargs -r -d 'n' git add --
# Track deleted files:
LANG=C git status | awk '$1 == "deleted:" { print $2; }' | xargs -r git rm --ignore-unmatch
LANG=C git status | grep -q '^nothing to commit' || {
git commit -m "Automated Jenkins commit at $(date '+%Y-%m-%d %H:%M')"
git push -q -u origin master
}
SAVE
Пояснения:
Метка “master” нужна, если у Дженкинса есть slave-узлы. Если их нет, метку в задании можете не указывать. Если они есть, то в списке узлов отредактируйте свойства мастера и в поле “Labels” добавьте “master”. Если вы этого не сделаете, Дженкинс попытается выполнять задание через агентов на всех узлах, а это явно не то, что нам требуется.
Если для подключения к Git-серверу используется SSH, перед выполнением задания не забудьте подключиться к нему вручную, чтобы git push не завершался с ошибкой из-за StrictHostKeyChecking.
Заключительный шаг в Gitlab’e после успешного git push:
в свойствах репозитория откройте раздел Members и понизьте уровень доступа для Дженкинса с Maintainer до Developer;
в Settings => Repository => Protected branches поменяйте для ветки “master” разрешение “Allow to push” с Maintainers на Maintainers+Developers.
Восстановление плагинов:
Т.к. мы сохраняем только манифесты плагинов, после восстановления из резервной копии нам потребуется просканировать каталог с манифестами и составить список команд для загрузки дистрибутивов:
sudo -Hiu jenkins
cd ~/plugins/
gawk 'BEGIN { RS = "rn" }
BEGINFILE { n = v = "" }
ENDFILE { printf "curl -sS -L -O http://updates.jenkins-ci.org/download/plugins/%s/%s/%s.hpin", n, v, n }
$1 == "Short-Name:" { n = $2 }
$1 == "Plugin-Version:" { v = $2 }
' ./*/META-INF/MANIFEST.MF > ./download_all_plugins.sh
Обратите внимание, что вместо awk используется gawk (GNU awk), т.к. классический awk не понимает BEGINFILE и ENDFILE. В некоторых дистрибутивах gawk устанавливается по умолчанию, в некоторых его потребуется установить вручную.
Если gawk отработает без ошибок, запустите сгенерированный им файл:
sudo -Hiu jenkins
cd ~/plugins/
gawk 'BEGIN { RS = "rn" }
BEGINFILE { n = v = "" }
ENDFILE { printf "curl -sS -L -O http://updates.jenkins-ci.org/download/plugins/%s/%s/%s.hpin", n, v, n }
$1 == "Short-Name:" { n = $2 }
$1 == "Plugin-Version:" { v = $2 }
' ./*/META-INF/MANIFEST.MF > ./download_all_plugins.sh
Самостоятельно распаковывать и устанавливать скачанные hpi-файлы не требуется — перезапустите Дженкинс и он сделает это сам.
Это особенно актуально для приложений, разработка которых ведется на компилируемых языках программирования. Используя эту возможность, вы сможете существенно сокращать размер вашего итогового образа не, прибегая к хитрым трюкам, которые я описывал в статье «6 советов по уменьшению Docker образа» Суть подхода заключается в том, чтобы не заботиться о количестве получающихся слоев в процессе сборки вашего приложения и копировать результаты сборки из одного образа в другой. В этой статье я покажу, как это реализуется на практике. Выдумывать ничего не буду, а просто покажу вам это на уже готовых примерах из официальной документации.
Процесс до появления многоэтапных сборок
Одной из самых сложных задач по созданию Docker образов является уменьшение размера итогового образа, ведь каждая команда в Dockerfile добавляет отдельный слой к итоговому образу. Поэтому нам всегда нужно помнить, что необходимо очищать любые не нужные нам артефакты в текущем слое, прежде чем перейти к следующему. Чтобы написать действительно эффективный Dockerfile, нам традиционно необходимо было использовать кучу shell-трюков, чтобы с одной стороны сделать как можно меньше слоев, а с другой, чтобы оставить в каждом созданном слое минимальное количество артефактов.
Вообще говоря, это очень распространенная практика использовать несколько Dockerfile-ов в одном проекте: один для разработки (содержит все необходимое для создания вашего приложения), другой оптимизированный для создания итогового образа, который будет использоваться в продуктиве, в котором должно быть только ваше приложение и все то, что необходимо для его запуска. Эта практика в свое время получила название «шаблон строителя». Однако, поддержание в актуальном состоянии двух Dockerfile-ов не есть что-то удобное.
Вот пример двух Dockerfile-ов (Dockerfile.build и Dockerfile), речь о которых идет выше:
Dockerfile:
FROM alpine:latest
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY app .
CMD ["./app"]
Dockerfile.build:
FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html
COPY app.go .
RUN go get -d -v golang.org/x/net/html
&& CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .
Когда вы запускаете build.sh скрипт, он создает первый образ, делает из него контейнер, чтобы скопировать артефакты, а затем создать второй образ. Оба образа занимают место на вашей системе, и еще какое-то место у вас занимают артефакты приложения на вашем локальном диске.
Многоэтапные сборки значительно упрощают эту ситуацию!
Использование многоэтапных (multi-stage) сборок
При многоэтапной сборке вы используете несколько операторов FROM в вашем Dockerfile. Каждая инструкция FROM использует произвольный базовый образ и начинает новый этап сборки. Вы можете выборочно копировать артефакты с одного этапа на другой, оставляя только то, что вам необходимо в конечном образе. Чтобы показать, как это работает, давайте адаптируем Dockerfile из предыдущего раздела для этого процесса.
Dockerfile:
FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html
COPY app.go .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .
FROM alpine:latest
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=0 /go/src/github.com/alexellis/href-counter/app .
CMD ["./app"]
Теперь вам нужен только один Dockerfile. Более того, вам больше не нужен и отдельный скрипт сборки. Просто запустите сборку образа привычной командой.
docker build -t avmaksimov/href-counter:latest .
Конечным результатом вашей является точно такой же крошечный продуктивный образ, однако сложность процесса значительно сократилась. Теперь вам не нужно создавать промежуточные образы, и вам больше не нужно извлекать промежуточные артефакты на вашу локальную систему.
Как это работает? Вторая команда FROM начинает новый этап сборки с базового образа alpine:latest. Инструкция COPY — from = 0 копирует артефакты с предыдущего этапа сборки на текущий этап, благодаря чему необходимые для сборки Go SDK и любые промежуточные артефакты не сохраняются в конечном образе.
Именование этапов сборки
По умолчанию этапы никак не называются, и вы ссылаетесь на них по их целочисленному номеру, начиная с 0 для первой инструкции FROM. Тем не менее, у вас есть возможность давать своим этапам понятные имена, добавив как в команду FROM. Этот пример улучшает предыдущий, используя имена для этапов. Это также означает, что даже если порядок инструкций в вашем Dockerfile со временем изменится, инструкции COPY не сломаются.
Dockerfile:
FROM golang:1.7.3 as builder
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html
COPY app.go .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .
FROM alpine:latest
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /go/src/github.com/alexellis/href-counter/app .
CMD ["./app"]
С появлением в Docker поддержки многоэтапных сборок управлять процессами самих сборок стало значительно проще. Надеюсь, вы это тоже оцените! Побольше вам автоматизации и поменьше ручных операций!
Многоступенчатая сборка Docker-образов
В прошлом я уже говорил о создании миниатюрных Docker-образов, но теперь, когда у Docker появилась многоступенчатая сборка, пришла пора вернуться к этому вопросу. Раньше нам приходилось создавать бинарный файл на одном шаге и собирать docker-образ на другом. Это было немного неудобно и требовало некоторых ухищрений. Давайте посмотрим, как многоступенчатые сборки улучшили ситуацию.
Замечание. Для этого нужен Docker 17.05 или более поздний.
Соберем ее с помощью образа golang:alpine одноступенчатым способом (single-stage build). Вот Dockerfile:
FROM golang:alpine WORKDIR /app ADD . /app RUN cd /app && go build -o goapp ENTRYPOINT ./goapp
Теперь соберем образ и запустим контейнер:
docker build -t treeder/hello . docker run --rm treeder/hello
Все работает, но давайте посмотрим на размер с помощью docker images | grep treeder/hello.
258 МБ — многовато для крошечного бинарного файла. Теперь давайте попробуем многоступенчатуюсборку (multi-stage build) с использованием нового Dockerfile:
# стадия сборкиFROM golang:alpine AS build-envADD . /src
RUN cd /src && go build -o goapp
# финальная стадияFROM alpine
WORKDIR /app
COPY --from=build-env /src/goapp /app/
ENTRYPOINT ./goapp
Соберем и запустим снова:
docker build -t treeder/hello . docker run --rm treeder/hello
Проверим размер:
6,35 МБ — намного лучше.
Что это означает? Что многоступенчатые сборки — отличная вещь. Ими стоит пользоваться практически в любом случае!
Jitsi Meet — это бесплатное программное обеспечение для видеоконференций с открытым исходным кодом на базе WebRTC, которое работает на Linux, macOS, Windows, iOS и Android. Если вы не доверяете Zoom, вы можете запустить собственную платформу для видеоконференций на собственном сервере. Преимущество Jitsi Meet заключается в том, что все ваши данные передаются только через ваш сервер, а шифрование TLS обеспечивает защиту от перехвата и прослушивания. Это руководство покажет вам, как установить Jitsi Meet на сервер Ubuntu 18.04 и 20.04, а также Debian 10.
ОСОБЕННОСТИ JITSI MEET
Совершенно бесплатно
Поделитесь экраном своего компьютера с другими (Screensharing)
Режим докладчика, который позволяет одновременно использовать экран и камеру
Вы можете поделиться системным звуком во время демонстрации экрана
Вы можете назначить авторизованных пользователей модераторами. Модератор может отключить звук у каждого участника одним щелчком мыши
Связь по сети зашифрована с использованием DTLS-SRTP
Сквозное шифрование
Вы можете установить пароль для своей конференции, чтобы предотвратить вход случайных незнакомцев
Запишите конференцию и сохраните ее в Dropbox
Транслируйте на YouTube Live и сохраняйте запись на YouTube
Приложения для Android и iOS
Текстовый чат
Вы можете поделиться текстовым документом
Телефонный доступ к конференции
Исходящий вызов телефонному абоненту
Вы можете встроить вызов Jits Meet на любую веб-страницу с помощью всего нескольких строк кода
СИСТЕМНЫЕ ТРЕБОВАНИЯ
Вам понадобится:
Linux сервер и non-root user с привилегиями sudo
Доменное имя, указывающее на ваш сервер
ШАГ 1. УСТАНОВИТЕ JITSI MEET ИЗ ОФИЦИАЛЬНОГО РЕПОЗИТОРИЯ ПАКЕТОВ
Jitsi Meet не включен в репозиторий Ubuntu по умолчанию. Мы можем установить его из официального репозитория пакетов Jitsi, который также содержит несколько других полезных программных пакетов. Войдите на свой сервер через SSH, затем выполните следующую команду, чтобы добавить официальный репозиторий Jitsi.
echo 'deb https://download.jitsi.org stable/' | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
Импортируйте открытый ключ Jitsi, чтобы менеджер пакетов APT мог проверять целостность пакетов, загруженных из этого репозитория.
Поскольку для репозитория Jitsi требуется HTTPS-соединение, нам нужно установить пакет apt-transport-https, чтобы APT установил HTTPS-соединение с репозиторием Jitsi.
sudo apt install apt-transport-https
Затем обновите локальный индекс пакета и установите Jitsi Meet в Ubuntu.
sudo apt update
sudo apt install jitsi-meet
Во время установки вам необходимо ввести имя хоста для вашего экземпляра Jitsi. Это имя хоста, которое будет отображаться в адресной строке веб-браузера, когда посетители присоединятся к вашей видеоконференции. Вы можете использовать описательное имя хоста, например meet.example.com.
На следующем экране вы можете выбрать создание нового самозаверяющего сертификата TLS (Generate a new self-signed certificate), чтобы позже вы могли получить и установить доверенный сертификат Let’s Encryption.
В процессе установки будут настроены некоторые параметры ядра Linux, которые сохраняются в файле /etc/sysctl.d/20-jvb-udp-buffers.conf. После завершения установки Jitsi Meet автоматически запустится. Вы можете проверить его статус с помощью:
Пакет jitsi-meet также извлекал другие пакеты в качестве зависимостей, например
openjdk-8-jre-headless: среда выполнения Java. Это необходимо, потому что Jitsi Meet написан на языке Java.
jicofo: Jitsi Conference Focus (systemctl status jicofo)
prosody: Легкий сервер Jabber / XMPP (systemctl status prosody)
coturn: сервер TURN и STUN для VoIP (systemctl status coturn)
ШАГ 2. ОТКРОЙТЕ ПОРТЫ В БРАНДМАУЭРЕ
Jitsi Meet прослушивает несколько портов UDP, что можно увидеть с помощью следующей команды. (Если на вашем сервере Ubuntu нет команды netstat, вы можете запустить команду sudo apt install net-tools, чтобы установить ее.)
sudo netstat -lnptu | grep java
Чтобы участники могли присоединиться к видеоконференции из веб-браузера, вам необходимо открыть TCP-порт 80 и 443. А для передачи видео по сети откройте UDP-порт 10000 и 5000. Если вы используете брандмауэр UFW, запустите следующую команду, чтобы открыть эти порты.
Перейдите в службу хостинга DNS (обычно это ваш регистратор домена), чтобы создать запись DNS A для вашего имени хоста Jitsi (meet.example.com). Затем запустите следующий скрипт, чтобы получить доверенный сертификат Let’s Encrypt TLS:
Введите свой адрес электронной почты, чтобы получать важные уведомления об учетной записи. Затем он загрузит certbot и получит сертификат TLS.
This script will:
- Need a working DNS record pointing to this machine(for domain jitsi.example.com)
- Download certbot-auto from https://dl.eff.org to /usr/local/sbin
- Install additional dependencies in order to request Let’s Encrypt certificate
- If running with jetty serving web content, will stop Jitsi Videobridge
- Configure and reload nginx or apache2, whichever is used
- Configure the coturn server to use Let's Encrypt certificate and add required deploy hooks
- Add command in weekly cron job to renew certificates regularly
You need to agree to the ACME server's Subscriber Agreement (https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf)
by providing an email address for important account notifications
Enter your email and press [ENTER]:
Если все в порядке, вы увидите следующее сообщение, указывающее, что сертификаты TLS были успешно получены и установлены.
Обратите внимание, что этот сценарий использует запрос http-01, что означает, что ваш веб-сервер Apache или Nginx должен прослушивать порт 80 общедоступного IP-адреса. Если ваша серверная среда не поддерживает вызов http-01, вам не следует запускать приведенный выше сценарий. Вам нужно использовать другие типы задач. В этом случае используем вызов DNS.
-a dns-cloudflare: используем плагин DNS cloudflare для аутентификации, потому что используем службу Cloudflare DNS.
-i nginx: использовать плагин nginx для установки сертификата TLS. Если вы используете Apache, вам необходимо заменить nginx на apache.
--redirect: принудительно использовать HTTPS с помощью 301 редиректа.
--hsts: добавлять заголовок Strict-Transport-Security к каждому ответу HTTP. Заставить браузер всегда использовать TLS для домена. Защищает от удаления SSL/TLS.
--staple-ocsp: включает сшивание OCSP. Допустимый ответ OCSP прикреплен к сертификату, который сервер предлагает во время TLS.
ШАГ 4. ВКЛЮЧИТЕ HTTP2
HTTP2 может улучшить скорость загрузки веб-страницы. Чтобы включить HTTP2 в Nginx, отредактируйте файл конфигурации виртуального хоста.
Сохраните и закройте файл. Затем перезагрузите Nginx, чтобы изменения вступили в силу.
sudo systemctl reload nginx
ШАГ 5. НАЧНИТЕ НОВУЮ ОНЛАЙН-ВСТРЕЧУ
Теперь посетите https://meet.example.com, и вы сможете начать конференцию. Для передачи звука вам необходимо разрешить веб-браузеру использовать ваш микрофон. А для передачи видео вам необходимо разрешить веб-браузеру доступ к вашей камере.
Дайте вашей встрече название и нажмите кнопку Go. После начала собрания вы можете при желании установить пароль для собрания.
ШАГ 6. НАСТРОЙТЕ АУТЕНТИФИКАЦИЮ ПОЛЬЗОВАТЕЛЯ
По умолчанию любой может перейти к вашему серверу Jitsi Meet, создать комнату и начать собрание. Чтобы настроить аутентификацию пользователя, отредактируйте файл конфигурации Prosody.
Измените его на следующее, что потребует от пользователя ввода имени пользователя и пароля для начала конференции.
authentication = "internal_plain"
Однако мы не хотим, чтобы участники вводили имя пользователя и пароль при присоединении к конференции, поэтому нам нужно создать анонимный вход для гостей, добавив следующие строки в конец этого файла. Обратите внимание, что вам не нужно создавать запись A DNS для guest.meet.example.com.
Теперь, если вы создаете комнату в Jitsi Meet, вам нужно будет ввести имя пользователя и пароль.
СОВЕТЫ ПО УСТРАНЕНИЮ НЕПОЛАДОК
Если вы столкнулись с ошибками, вы можете проверить журнал ошибок Nginx (/var/log/nginx/error.log), чтобы узнать, что не так. Также проверьте журналы служб systemd.
Если вы видите ошибку You have been disconnected (Вы были отключены) при запуске собрания в Jitsi, возможно, вы забыли изменить meet.example.com на свое настоящее имя хоста Jitsi Meet в файлах конфигурации.
ОПЦИОНАЛЬНО: НАСТРОИТЬ JIGASI ДЛЯ ТЕЛЕФОННОГО НАБОРА ИЛИ ИСХОДЯЩЕГО ВЫЗОВА
Jitsi предлагает телефонный интерфейс, который позволяет пользователям подключаться к конференции или делать звонки с напоминанием. Установите пакет jigasi (шлюз Jitsi для SIP).
sudo apt install jigasi
Во время установки вам нужно будет ввести свое имя пользователя и пароль SIP. Если у вас его нет, вы можете создать бесплатную учетную запись SIP на сайте OnSIP.com.
Если вы настроили аутентификацию пользователя на шаге 6, вам необходимо отредактировать файл конфигурации Jigasi.
Сохраните и закройте файл. Перезапустите службу jigasi systemd.
sudo systemctl restart jigasi
ОПЦИОНАЛЬНО: НАСТРОИТЬ COTURN
Если во время установки Jitsi Meet вы видите следующее сообщение, вам необходимо настроить Coturn, чтобы он работал правильно.
Warning! Could not resolve your external ip address! Error:^
Your turn server will not work till you edit your /etc/turnserver.conf config file.
You need to set your external ip address in external-ip and restart coturn service.
Отредактируйте файл конфигурации Coturn.
sudo nano /etc/turnserver.conf
Найдите следующую строку.
external-ip=127.0.0.1
Замените 127.0.0.1 общедоступным IP-адресом вашего сервера. Сохраните и закройте файл. Затем перезапустите Coturn.
sudo systemctl restart coturn
ИТОГИ
Готово! Мы успешно установили Jitsi Meet на наш Linux сервер.
