DevOps, Productivity, Career // etogeek blog

Maintenance-режим в Nginx

Mon, 27 Oct 2025 00:00:00 +0000

This post is also available in English.

Что это такое?
#

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

Сейчас мы умеем раздавать определенную html-страничку вместо стандартной страницы ошибки.

Например вместо дефолтной 504 ошибки мы можем отдавать красивую страницу с логотипом компании и вежливой понятной фразой вроде “Сейчас сервис недоступен, мы уже знаем о проблеме, попробуйте через минутку”.

error_page 500 501 503 502 504 /static/errors/5xx.html

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

Вторая ситуация: сервис жестко упал, инженеры решают инцедент, а клиенты в это время видят то 500-ки, то 503, то 504-ки, то таймауты. Включим maintenance-режим и всем будет спокойнее.

Неудачная попытка
#

Первое что нашлось в интернете на эту тему: через if проверяйте наличие файла на сервере (например /etc/nginx/maintenance.flag), если файл есть - отдаем страницу, если нет - идем по стандартному nginx-конфигу. Что-то типа такого:

server {
  	....
  	error_page 503 /maintenance.html;
	
  	location = /maintenance.html {
  	    root /etc/nginx/maintenance/;
  	    internal;
  	}
	
  	location / {
  	  if (-f /etc/nginx/maintenance.flag) {
  	     return 503;
  	  }
  	  proxy_pass http://127.0.0.1:3000;
  	}
}

Это вполне рабочий вариант, но здесь наличие файла проверяется на КАЖДЫЙ запрос. Это может быть ресурсозатратным. На dev-стенде всё прошло хорошо, а на проде начало вызывать тормоза.

Почему return 503?
#

Почему нужно возвращать клиенту 503 код ответа, несмотря на то, что мы отдаем живую работающую html-страницу?

503 код обычно означает, что сервис временно недоступен, там проводятся работы или он перегружен. Подробнее.

503 код ответа не индексируется поисковиками. Представь, если робот гугла в момент даунтайма спарсит страницу твоего проекта и запишет у себя “Under maintenance”.

Так же клиентским браузерам надо запрещать кэшировать такие страницы, чтобы после завершения даунтайма пользователь не ходил на maintenance-страничку из кэша.

Как можно сделать через include конфигурации?
#

Общая логика такая:

у нас есть файл maintenance_on.conf в котором одна строка: return 503;
по необходимости исклюдим этот файл в нужные locations череш include maintenance_on.conf
мягко рестартим Nginx (через reload)

Теперь подробности реализации:

Создаем директорию, чтобы не было мусора: mkdir /etc/nginx/maintenance
В нее кладем нашу maintenance.html страничку. Навайбкодьте…
Создаем конфиг-файл maintenance_on.conf:

return 503;

Создаем пустой конфиг-файл maintenance_off.conf
Создаем симлинк maintenance_current.conf

ln -sfn /etc/nginx/maintenance/maintenance_off.conf /etc/nginx/maintenance/maintenance_current.conf

Нужно добавить немного строк в nginx-конфиг в блок server:

server {
		...
    error_page 503 /maintenance.html;

    location = /maintenance.html {
        internal;
        root /etc/nginx/maintenance/maintenance.html;
        add_header Cache-Control "no-store" always;
        add_header Retry-After "3600" always;
    }

    location / {
        include /etc/nginx/maintenance/maintenance_current.conf;
        ...
    }
}

Что здесь происходит:

Мы говорим, чтобы Nginx редиректил на /maintenance.html при 503 ошибке
Настраиваем локейшен /maintenance.html, который отвечает за раздачу нашей сервисной странички. internal нужен, чтобы клиент не мог вообще никак запросить /maintenance_on.conf или любой другой файл.
Добавляем заголовки, чтобы клиентский браузер не кэшировал страничку, а также Retry-After.
В основной location (или в любой другой) добавляем include нашего симлинка.

Таким образом, чтобы включить maintenance-режим нам нужно только поменять симлинк и мягко перезапустить Nginx:

ln -sfn /etc/nginx/maintenance/maintenance_on.conf /etc/nginx/maintenance/maintenance_current.conf
nginx -t && systemctl reload nginx

Для выключения создаем линк на _off-файл и опять перезапускаем Nginx.

Как автоматизировать - сами придумайте.

Sentry сожрал все место на диске

Wed, 01 Oct 2025 00:00:00 +0000

Если вы когда-нибудь поднимали self-hosted (on premise) версию Sentry, то знаете, что лезть туда очередной раз сильно не хочется: там ~38 контейнеров. Но иногда возникают нештатные ситуации.

Пару раз у меня случалось так, что какой-то сервис начинает сбоить и без конца отправлять в Sentry ошибки и евенты. Огромное количество ошибок (десятки и сотни тысяч). В такой ситуации я наблюдал два варианта развития событий:

Стремитально заканчивается место на диске:
Запредельно возрастает нагрузка на оперативную память:

Закончилось место на диске
#

Проверяем место на дисках, смотрим какие директории(вольюмы) больше всего жрут места:

du -Sh / | sort -rh | head -

Если в выводе на первых местах будут вольюмы sentry-kafka - значит двигаемся в верном направлении. Получается, что наши эвенты попали в Kafka, но еще не пошли дальше в сторону основной базы.

Я во все команды docker compose добавляю --env-file .env.custom, так как он используется для запуска моего инстанса Sentry.

Если вы перед этим выключили Sentry полностью, то сейчас стоит включить только Kafka:

docker compose --env-file .env.custom up -d kafka

Заходим внутрь контейнера с Kafka и смотрим размер топиков:

docker compose --env-file .env.custom exec -ti kafka bash
kafka-log-dirs --describe --bootstrap-server localhost:9092 --topic-list ingest-events
kafka-log-dirs --describe --bootstrap-server localhost:9092 --topic-list events

Чтобы освободить место занятое евентами, которые лежат в топиках, надо пойти немного хитрым способом: мы установим retention на очень маленькое значение (1 секунда), а потом вернем обратно.

# устанавливаем retention
kafka-configs --zookeeper zookeeper:2181 --entity-type topics --alter --entity-name ingest-events --add-config retention.ms=1000
kafka-configs --zookeeper zookeeper:2181 --entity-type topics --alter --entity-name events --add-config retention.ms=1000

# ждем пока освободится место (1-10 минут)

# откатываем назад
kafka-configs --zookeeper zookeeper:2181 --entity-type topics --alter --entity-nameingest-events--delete-config retention.ms
kafka-configs --zookeeper zookeeper:2181 --entity-type topics --alter --entity-nameevents--delete-config retention.ms

Теперь нужно сбросить offset-ы в топиках:

kafka-consumer-groups --bootstrap-server kafka:9092 \
  --group snuba-consumers --topic ingest-events \
  --reset-offsets --to-latest --execute

kafka-consumer-groups --bootstrap-server kafka:9092 \
  --group ingest-consumer --topic ingest-events \
  --reset-offsets --to-latest --execute

kafka-consumer-groups --bootstrap-server kafka:9092 \
  --group post-process-forwarder --topic events \
  --reset-offsets --to-latest --execute

Но сброс оффсетов может не помочь. Читай раздел ниже про траблшутинг.

На этом вроде всё.

Забита вся оперативная память
#

Это ситуация, когда евенты прошли дальше Kafka, уже в Redis. Это видно по тому, что, собственно, Redis начинает использовать очень много оперативки. Можно посмотреть через htop, docker stats или ctop.

Проблема в том, что Redis - это in-memory хранилище, и если значений становится очень много, они перестают умещаться в память, а дальше цепная реакция приводящая к приходу OOM-Killer.

Здесь решение комплексное:

# идем в контейнер с Redis
docker compose --env-file .env.custom exec -ti redis sh

# смотрим какой сейчас eviction policy настроен
redis-cli info | grep maxmemory_policy

# скорее всего там стоит noeviction, что значит, что Redis будет использовать всю доступную оперативку, а потом перестанет обрабатывать новые запросы
# поменяем тип политики, и установим лимит maxmemory, на что-то разумное
redis-cli CONFIG SETmaxmemory-policy volatile-ttl
redis-cli CONFIG SETmaxmemory 7G

Эти настройки слетят после перезапуска контейнера, поэтому их следует закрепить в конфиг файле.

Добавляем конфиг-файл для Redis
#

Создаем директорию и файл для конфига:

mkdir redis
nano redis/redis.conf

# туда вставляем настройки
maxmemory 7G
maxmemory-policy volatile-ttl

Теперь надо этот файл подмонтировать в контейнер с Redis. Сделаем это через создание override файла nano docker-compose.override.yml:

services:
  redis:
    command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
    volumes:
      - ./redis/redis.conf:/usr/local/etc/redis/redis.conf

Теперь перезапускаем Redis и проверяем, что настройки подцепились. Можно через docker inspect, но еще лучше будет зайти внутри контейнера и поgrep-ать их из redis-cli info.

Я еще делал redis-cli flushall чтобы очистить весь кэш и освободить память.

После всех процедур обязательно проверяйте, что контейнеры запущены и не рестартуются, что новые эвенты прилетают.

Траблшутинг Kafka после очистки топиков
#

После всех этих процедур эпопея с Kafka не закончилась. Некоторые consumers со временем начинали вылетать с ошибками в логе:

arroyo.errors.OffsetOutOfRange: KafkaError{code=_AUTO_OFFSET_RESET,val=-140,str="fetch failed due to requested offset not available on the broker: Broker: Offset out of range (broker 1001)"}

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

kafka-consumer-groups --bootstrap-server kafka:9092 --delete --group ingest-consumer
kafka-consumer-groups --bootstrap-server kafka:9092 --delete --group snuba-consumers
kafka-consumer-groups --bootstrap-server kafka:9092 --delete --group post-process-forwarder
kafka-consumer-groups --bootstrap-server kafka:9092 --delete --group post-process-forwarder-errors
kafka-consumer-groups --bootstrap-server kafka:9092 --delete --group post-process-forwarder-transactions

Тоже не помогло, через некоторое время консюмеры начали рестартиться.

Более мощный способ - это грохнуть volume kafka и zookeeper полностью через docker volume rm.

docker compose --env-file .env.custom down
docker volume rm sentry-kafka sentry-zookeeper
docker volume rm ah_sentry_sentry-kafka-log ah_sentry_sentry-zookeeper-log

После этого надо создавать топики заново, и в моем случае самым простым способом оказалось прогнать ./install.sh скрипт заново. Он учитывает наличие .env.custom, не трогает Postgres и в целом очень мягко бутстрапит заново все что нужно.

Reference: часть гайда взята из статьи Юрия на Medium. Спасибо ему большое. Статья уже не раз мне помогала.

Как я использую Ansible для управления инфраструктурой?

Tue, 22 Apr 2025 00:00:00 +0000

Если вы давно читаете этот канал, то точно знаете, что я люблю Ansible и использую его для управления инфрой на текущих проектах.

Здесь я хотел рассказать как именно я структурирую inventory-файлы, переменные, роли и как это все запускаю. Может это не супер-бест-практисы, но это работает довольно давно, неплохо поддерживается. У Ansible есть свои минусы, но тут не об этом.

Это НЕ гайд «как надо делать».
Здесь не будет пошаговых инструкций. Здесь — демонстрация того, как делаю я. Может быть это даст вам каких-нибудь идей, или вы захотите поделиться своим мнением в комментариях в Телеграм-чате.

В интернете over9000 гайдов типа создаете группу хостов web-servers, создаете плейбук, который запускаете на этой группе и устанавливаете nginx. Для базы данных тоже самое. Сколько таких плейбуков и групп получится, если у вас 100 серверов с разным наполнением? Нужно что-то другое.

Роли
#

Во-первых: роли. Роль — это набор заданий, параменных, шаблонов которые объединены в отдельный модуль. Например роль для установки и настройки Nginx, роль для управления пользователями, роль для установки и настройки PostgreSQL.

Роль должна выполнять одну задачу.

Роль должна быть универсальной: мы можем запустить ее на любом хосте и она сделает то, что должна.

С помощью переменных в роль можно передавать различные настройки.

В основном все роли я пишу сам, а не использую готовые из коммьюнити. Мне кажется, что коммьюнити-роли перегружены дополнительными параметрами. Я могу взять что-нибудь интересное из них, это да. Но в основном — пишу сам под свои требования.

Inventory
#

Во-вторых: inventory. Про него я уже писал. Вот тут. Инвентарь — это файлы, где мы описываем нашу инфраструктуру. Базово — это список групп и хостов, на которых будут запускаться наши плейбуки. Но так же в inventory мы можем указывать переменные для наших хостов. Тут и начинается iNfRaStRuCtUrE aS cOdE.

Напомню структуру инвентори здорового человека:

ansible/inventories
├── dev
│   ├── dev.yml
│   ├── group_vars
│   │   ├── all.yml
│   └── host_vars
│       ├── server00dev.et.yml
│       └── frontend01dev.et
│           ├── common.yml
│           ├── logrotate.yml
│           └── promtail.yml
├── dwh_cluster
│   ├── dwh.yml
│   ├── group_vars
│   │   ├── all.yml
│   │   ├── dwh_cluster.yml
│   │   └── dwh_cluster_wo_dwh00.yml
│   └── host_vars
│       ├── dwh00.et
│       │   ├── backups.yml
│       │   ├── blackbox-exporter.yml
│       │   └── common.yml
│       ├── dwh01.et.yml
│       └── dwh50.et.yml
...

Я держу поддиректории под окружения. В каждой поддиректории есть .yml файл, который содержит только список хостов. Максимум туда добавляем настройки подключения, например ansible_host, etc…:

all:
  children:
    server00:
      hosts:
        server00dev.et:

Есть директории host_vars и group_vars в которых хранятся файлы с названиями хостов из инвентори, в них находятся все переменные-настройки хостов. Так же если host_var-файл разрастается и становится сложно его поддерживать, его можно превратить в директорию с несколькими файлами (см. выше в примере).

Что в host_var-файле у меня есть интересного? Одна из самых важных, на мой взгляд, переменных:

host_roles:
  - openjdk
  - promtail
  - haproxy
  - postgresql

Она указывает КАКИЕ РОЛИ нужно запустить на ЭТОМ хосте.

Так же есть, например, переменная users, в которой я перечисляю дополнительных пользователей, которых нужно создать на сервере. В этом же файле я указываю “настройки” для моих ролей, например:

postgresql_version: 16
postgresql_global_config_options:
  - { option: listen_addresses, value: '0.0.0.0' }
  - { option: max_connections, value: '500' }

или

iptables_additional_rules:
  - -A INPUT -s 172.16.0.0/12 -m comment --comment "allow from docker containers" -j ACCEPT
  - -A INPUT -s 10.40.12.0/24 -m comment --comment "allow from vpn network" -j ACCEPT

В последнее время я иду к тому, что в inventory указываю полноценные конфиги для сервисов, например для promtail. Прямо внутри переменной описываю конфигурацию, а роль уже добавит этот конфиг к дефолтному:

promtail_config_scrape_configs:
  - job_name: backend_dev_rest
    static_configs:
      - targets:
          - localhost
        labels:
          job: backend_dev_rest
...

Это позволяет мне иметь при необходимости уникальный (кастомный) конфиг для какого-либо сервиса вместо оригинально (или в дополнение к нему). Например на всех хостах у меня есть дефолтный конфиг promtail - он указан в roles/promtail/defaults, а в host_vars я его дополняю.

Плейбук
#

В-третьих: как это запускать?

У меня есть “общий” плейбук common.yml, в котором по сути есть всего один таск include_role. В этот таск предается список ролей содержащий:

обязательные роли, которые должны быть прокатаны на всех хостах, например node_exporter, zabbix_agent, настройки ssh, установка правильного хостнейма, настройки DNS, NTP и так далее.
роли из переменной host_roles

Так как в host_roles у меня лежит список (тип данных) ролей, то этот список просто расширит уже имеющийся список дефолтных. Я добавляю jinja-фильтр default([]), чтобы смержить туда пустой список, если переменная host_roles вообще не задана, иначе будет ошибка. Итогово это выглядит так:

- name: All hosts playbook
  hosts: all
  become: true
  gather_subset: ['default_ipv4', 'distribution_release']
  ignore_unreachable: false

  tasks:
    - name: Include roles
      ansible.builtin.include_role:
        name: "{{ item }}"
      loop:
        - common_software
        - users
        - "{{ host_roles | default([]) }}"
        - "{{ group_roles | default([]) }}"
        - ntp
        - node-exporter
        - zabbix_agent
        - sshd

Теперь, если я хочу настроить сервер с нуля (ну, не совсем с нуля, конечно), то я просто запускаю:

ansible-playbook common.yml -i inventories/dev -l server00dev.et -D

И он прокатится только на одном сервере. Уберу -l server00dev.et, и плейбук запустится на всех дев-серверах.

Автоматизация
#

В-четвертых: как это автоматизировать? Это немного не укладывается в рамки стандартного CI/CD (где сборка/загрузка/деплой) - я скорее про автоматическую раскатку этого поделия на серверы.

Предположим, что мы описали и добавили все наши серверы в inventory, разделили его на окружения: inventories/dev/dev.yml, inventories/dev/prod.yml. В host_vars и group_vars добавили нужные нам роли для хостов, конфиги и параметры для сервисов. Как будем это запускать?

Весь инфраструтурный код я храню в отдельном репозитории, который гордо обозвал ansible. Я хочу, чтобы при изменении кода у меня автоматически запускался ansible-playbook common.yml.

Я себе выбрал такие условия:

если меняется что-то в inventories/dev, то запустить common.yml с параметром -i inventories.dev
аналогично для prod-окружения

Так как я использую Gitlab, то у меня есть .gitlab-ci.yml файл. В нем я описываю условия, которые стриггерят запуск плейбука:

deploy_dev:
  stage: deploy
  before_script:
    - mkdir -p ~/.ssh
    - echo "$ADMIN_SSH_PRIVATE_KEY" | base64 -d > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
  script:
    - ansible-playbook -i inventories/dev common.yml --diff
  rules:
    - if: '$CI_PIPELINE_SOURCE == "web"'
      when: manual
    - if: '$CI_COMMIT_BRANCH == "master"'
      changes:
        - 'inventories/dev/**/*'
        - 'roles/node-exporter/**/*'
        - 'roles/users/**/*'
        ...

Таким образом этот пайплайн запустится автоматически в случае изменений в файлах под inventories/dev, а так же при изменениях в некоторых ролях — например я глобально обновил версию node-exporter в defaults.

Общий workflow (реальный и идеальный)
#

Инженер клонирует себе репозиторий
Создает отдельную ветку, вносит необходимые изменения.
Проверяет через check-mode со своего компьютера — вот этот пункт - плохой паттерн, так как он требует доступа на сервера, и может вызывать configuration drift. Проверку должен выполнять CI.
Пушит код в Gitlab, создает MR.
В Gitlab проходят тесты (идеальный вариант), другой инженер проводит код-ревью.
MR мержится в master-ветку
Gitlab запускает соответствующий пайплайн, чтобы привести инфрастркутуру к целевому состоянию

Что надо добавлять?
#

Тестирование. Как минимум — прогон через check-mode. Как идеал — тестирование ролей на временной инфрастркутуре.
Линтеры. Нужно прогонять код, чтобы он соответствовал правильному синтаксису.

Было полезно? Может появились какие-то идеи? Или вы делаете у себя в инфрастркутуре по-другому? Поделись этим в 👉 телеграм-чате! Мне очень интересно было бы почитать.

Настройка ansible.cfg. Зачем и как?

Mon, 13 Jan 2025 00:00:00 +0000

ansible.cfg — это файл с различными настройками для Ansible. По умолчанию Ansible будет искать этот файл в разных местах.

Если мы храним наши ansible-плейбуки в git-репозитории и прокатываем их автоматизированно, с помощью CI-системы (Jenkins, Gitlab CI, etc), то мы можем хранить конфиг-файл прямо в корне нашего репозитория.

С помощью команды ansible-config init –disabled > ansible.cfg можно сгенерить файл со всеми настройками, но в закомментированном виде.

Конфиг описывается в ini-формате и разбит на категории, вроде [defaults]. Все эти настройки можно так же передать программе через переменные окружения, типа ANSIBLE_PIPELINING=True

Вот пример моего ansible.cfg файла:

[defaults]
host_key_checking=False
pipelining = True
strategy = free
callbacks_enabled = timer, profile_roles
forks = 40
deprecation_warnings=False
stdout_callback = yaml

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=60s
retries=3

host_key_checking - отвечает за проверку host keys. ⚠️ Небезопасно, используйте с осторожностью. (ну, я должен это написать)
pipelining - ansible поднимает ssh-сессию для каждой команды. Pipelining позволяет протолкнуть сразу несколько команд через одну сессию. Это существенно может ускорить выполнение заданий, но разработчики предупреждают, что это может вызывать проблемы, если на серверах включен requiretty в /etc/sudoers.
strategy - стратегия выполнения тасок. free позволяет выполнять таски на разных хостах асинхронно. Например у тебя есть task1, task2, task3. По умолчанию Ansible будет ждать, пока task1 завершится на всех хостах.
callbacks_enabled - включает различные callback плагины. Например, для отображения времени выполнения тасок.
forks - указываем максимальное количество параллельных подключений. По умолчанию - 5, что довольно мало. Увеличение этого числа сильно ускоряет выполнение плейбуков на больших инвентори, но и увеличивает нагрузку на процессор.
deprecation_warnings - отключаем различные уведомления о deprecated функционале.
stdout_callback = yaml - помогает лучше отформатировать вывод ошибок и дебаг-команд. Подробнее.
Под группой [ssh_connection] содержатся различные настройки для SSH-подключений, примерно такие же какие мы можем указать в ssh-config файле.

Так же в переменных окружения я передаю:

ANSIBLE_VAULT_PASSWORD_FILE: '/tmp/vault.pass' - путь к файлу, где лежит пароль от ansible-vault. Мы же не храним его в репозитории, а прокидываем в среду исполнения извне (например из Gitlab Variables или Infisical).
ANSIBLE_DISPLAY_OK_HOSTS: 'False' и ANSIBLE_DISPLAY_SKIPPED_HOSTS: ‘False’, чтобы не выводить информацию об ОК- и SKIPPED-хостах, зачем этот мусор…

В общем и целом, использование ansible.cfg — это довольно удобный способ указать глобальные настройки при работе с репозиторием несколькими инженерами или с помощью систем автоматизации.

Как установить Gitlab Runner в Docker Swarm

Sun, 18 Aug 2024 10:06:32 +0000

This post is also available in English.

У меня в проекте есть кластер Docker Swarm, в котором динамически запускаются Jenkins Agents, на которых выполняются все джобы из Jenkins. Почему не в Kubernetes? Потому что держать Кубер-кластер только для джобов - неоптимально, Swarm сильно проще в поддержке. Вот даже есть пост “ Не усложняй”.

Недавно разворачивал Self-Hosted Gitlab, но не нашел официальной инструкции, чтобы запустить gitlab runner в swarm-кластере, чтобы еще autoscaling работал — то есть чтобы runner сам поднимал дополнительные контейнеры на swarm-нодах. Пришлось собирать по крупицам информацию. Вот, делюсь способом.

Инструкция состоит из трех этапов:

Получить токен для регистрации
Разложить конфигурации раннеров на машины
Задеплоить раннеры

Получить Runner Authentication Token
#

Раньше для регистрации раннеров использовался runner registration token, но он перешел в статус Deprecated. Gitlab начал использовать Runner Authentication Token для подключения раннеров.

Идем в настройки проекта, группы или всего инстанса, чтобы зарегистрировать новый Runner: Admin Settings -> CI/CD -> Runners -> New instance runner:

Указываем Tags. В последствие мы будем указывать тэги в наших gitlab-ci пайплайнах, чтобы они запускались на определенных раннерах. Например, у меня это тэг swarm.

На следующей странице копируем токен и сохраняем где-нибудь:

Теперь Gitlab будет ждать, что какой-нибудь раннер зарегистрируется с этим токеном.

Конфигурация раннеров
#

Мы можем запустить контейнер с gitlab runner, зайти в него и выполнить указанную команду register. Gitlab Runner при регистрации сохранит токен и минимальные настройки в файл /etc/gitlab/config.toml внутри контейнера. Но чтобы не ходить на каждой машине в контейнер и не делать все руками, давай сделаем шаблон конфигурации и разложим его на swarm-ноды.

Готовим конфигурационный файл:

concurrent = 5 # Concurrent containers per node
check_interval = 0

[[runners]]
  name = "docker-swarm-runner"
  url = "https://<YOUR-GITLAB-INSTANCE>/"
  token = "<GITLAB AUTHENTICATION TOKEN>"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.docker]
    tls_verify = false
    image = "alpine:latest"  # Default image for jobs
    privileged = true  # If we need Docker-in-Docker
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    allowed_pull_policies = ["always", "if-not-present", "never"]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]

Меняем token на тот, который получили в прошлом этапе. Так же указываем адрес нашего Gitlab-инстанса.

Теперь на каждой swarm-ноде нужно создать директорию для конфигурации и положить туда этот файл. Как это сделать — решайте сами, я использую Ansible.

Главное, помните, что хранить токен в git-репозитории небезопасно. Это плохая практика. В случае Ansible вы можете воспользоваться Ansible Vault или сторонними решениями, типа Hashicorp Vault или Insfisical.

Копируем конфигурационный файл на ноды
#

Вот пример Ansible-кода для копирования конфигурационного файла:

templates/config.toml.j2:

concurrent = 5
check_interval = 0

[[runners]]
  name = "docker-swarm-runner"
  url = "{{ gitlab_instance_url }}"
  token = "{{ gitlab_runner_swarm_auth_token.value }}"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.docker]
    tls_verify = false
    image = "alpine:latest"  # Default image for jobs, can be overridden in .gitlab-ci.yml
    privileged = true  # Enable if you need to run Docker-in-Docker or privileged containers
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    allowed_pull_policies = ["always", "if-not-present", "never"]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]

tasks/main.yml:

- name: Create directories
  ansible.builtin.file:
    path: /etc/gitlab-runner/config
    state: directory
    recurse: true

- name: Copy config file
  ansible.builtin.template:
    src: config.toml.j2
    dest: /etc/gitlab-runner/config/config.toml

Конфигурационный файл должен быть на всех нодах swarm-кластера.

Деплой Gitlab Runner в Swarm
#

Swarm работает с привычными docker-compose файлами, поэтому создаем такой. Для копирования я так же пользуюсь Ansible, поэтому вот пример jinja-шаблона:

services:
  gitlab-runner:
    image: gitlab/gitlab-runner:{{ gitlab_runner_image_version }}
    deploy:
      mode: global
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc/gitlab-runner/config:/etc/gitlab-runner
    networks:
      - gitlab-net

networks:
  gitlab-net:
    external: false

Обратите внимание:

мы указываем deploy mode: global, чтобы контейнер запустился на всех нодах кластера. Это как DaemonSet в Kubernetes.
мы подключаем директорию с config.toml файлом
дополнительно мы монтируем docker socket, чтобы gitlab runner мог управлять нашим docker engine и создавать новые контейнеры (это нужно для работы autoscaling)
указываем версию gitlab-runner контейнера, посмотреть доступные можно в Docker Hub.

Я копирую этот файл с помощью Ansible:

- name: Copy compose file
  ansible.builtin.template:
    src: docker-compose.yml.j2
    dest: /etc/gitlab-runner/docker-compose.yml

Запускать swarm stack нужно с менеджер-ноды (главной ноды кластера), но сам файл будет лежать на всех нодах. Избыточно, но мне так проще, чтобы не добавлять условия в Ansible.

Идем на менеджер-ноду и выполняем:

docker stack deploy -c docker-compose.yml gitlab-runner

Через минутку проверяем:

root@swarm-node01:/home/ysemyenkov# docker stack ps gitlab-runner
ID             NAME                                                    IMAGE                                 NODE           DESIRED STATE   CURRENT STATE        ERROR     PORTS
pnkxq7yf3wm3   gitlab-runner.1tlong-name   gitlab/gitlab-runner:ubuntu-v17.3.0   swarm-node01   Running         Running 2 days ago
ih4822qch9ew   gitlab-runner.3tlong-name   gitlab/gitlab-runner:ubuntu-v17.3.0   swarm-node03   Running         Running 2 days ago
xzj5yt1cv5ae   gitlab-runner.2tlong-name   gitlab/gitlab-runner:ubuntu-v17.3.0   swarm-node02   Running         Running 2 days ago

Если все нормально, то в Gitlab мы увидем зарегистрированный Runner:

Проверяем работу
#

Можем создать тестовый пайплайн, который запустит десяток джобов одновременно:

stages:
  - test

parallel-jobs:
  stage: test
  tags:
    - swarm
  script:
    - echo "Starting sleep for 600 seconds"
    - sleep 600
  parallel:
    matrix:
      - JOB_NAME: "job1"
      - JOB_NAME: "job2"
      - JOB_NAME: "job3"
      - JOB_NAME: "job4"
      - JOB_NAME: "job5"
      - JOB_NAME: "job6"
      - JOB_NAME: "job7"
      - JOB_NAME: "job8"
      - JOB_NAME: "job9"
      - JOB_NAME: "job10"

Запускаем пайплайн и видим, что контейнеры запустились в нужном количестве и на разных нодах. Посмотреть можно как через docker ps на нодах, так и через средства мониторинга. Например я смотрю метрики cAdvisor в Grafana:

Видим, что три верхних контейнера — это основные процессы gitlab-runner, которые получают задания и создают динамические контейнеры под джобы. А ниже, наши контейнеры с sleep джобами запущенны параллельно на разных нодах.

Вот и всё.

🙋‍♂️С комментариями можно смело приходить в наш телеграм-чат.

🌀Так же рекомендую подписаться на телеграм-канал, чтобы не пропускать классные посты и анонсы новых статей.

🎬 А видео выходят на Youtube, канал @etogeek.

Аутентификация и авторизация. В чем разница?

Thu, 18 Apr 2024 00:00:00 +0000

Авторизация и аутентификация — похожие слова с различными значениями, которые легко спутать. Давайте разберемся, в чем же разница.

Аутентификация
#

Аутентификация — это процесс, который позволяет удостовериться, что вы тот, кем себя представляете. Примером аутентификации служит ввод логина и пароля. Система проверяет эти данные и подтверждает вашу идентичность.

В системах на базе Linux, аутентификация происходит с помощью файлов:

/etc/passwd — хранит информацию о пользователях.
/etc/shadow — содержит зашифрованные пароли пользователей.
/etc/nsswitch.conf — указывает, где искать информацию о пользователях, группах и других ресурсах, включая DNS или сервисы сетевых файловых систем. Этот файл направляет систему искать данные в локальных файлах или, например, в LDAP.

Авторизация
#

Авторизация наступает после аутентификации и определяет, к каким ресурсам или действиям у вас есть доступ. Она проверяет, разрешено ли вам доступ к определенным разделам сервиса.

В Linux права доступа определяются через:

/etc/group — описывает группы пользователей и их членов.
/etc/sudoers — указывает, кто может исполнять команды с правами суперпользователя.

Пример из жизни
#

Когда вы показываете паспорт на границе, это аутентификация — вы подтверждаете, что вы Вася Петров. Определение того, можно ли вам выезжать из страны, является вопросом авторизации.

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

Прокомментировать статью, поделиться идеями, поболтать и задать вопрос можно в 👉 телеграм-чате, а так же обязательно подписаться на 👉 телеграм-канал!

SLI, SLO и SLA. В чем разница?

Sun, 18 Feb 2024 00:00:00 +0000

Эти три аббривеатуры максимально плотно связаны между собой.

SLI — Service Level Indicator
#

Это числовое значение какой-то конкретной характеристики, метрика: время отклика, задержка запросов, частота ошибок. Обычно берутся значения за период времени, усредняются и переводятся в проценты.

Это наша мера успеха.

«Наш сайт был доступен 99% времени за прошлый месяц» — это SLI. Внезапно, это не SLA, как многие привыкли говорить.

SLO — Service Level Objective
#

Это наша цель. Числовое значение, которого мы хотим достичь и не проваливаться ниже этой границы. Измеряем через SLI. Задает уровень ожиданий от сервиса. Например, SLO = среднее время отклика должно быть ≤100ms

«Мы стремимся, чтобы наш сайт был доступен 99% времени» — это SLO.

SLA — Service Level Agreement
#

Отвечает на вопрос «Что случится если SLO не соблюдаются?».

Это явный или неявный контракт с клиентами или пользователями системы в котором описаны последствия несоответствия SLO.

«Будет предоставлена компенсация в случае, если наш сайт будет доступен менее 99% времени» — это SLA

Зачастую используются внутренние SLO, более жесткие, чем те, что мы показываем пользователям. Например, мы утверждаем, что система доступна 99,9% времени, а инженерная команда стремится обеспечивать 99,99%, таким образом появляется некий буфер перед штрафами по SLA.

TL;DR;
#

Помните, что SLI — это измерение, SLO — это цель, а SLA — это обязательство.

🙋‍♂️С комментариями можно смело приходить в наш телеграм-чат.

🌀Так же рекомендую подписаться на телеграм-канал, чтобы не пропускать классные посты и анонсы новых статей.

🎬 А видео выходят на Youtube, канал @etogeek.

Как закоммитить только часть файла?

Thu, 08 Feb 2024 00:00:00 +0000

TL;DR;
#

git add -p

Чуть подробнее
#

Команда git add -p (или --patch) проходит по всем файлам и спрашивает по каждому изменению, что ты хочешь с ним сделать:

❯ git add -p
diff --git a/ansible/file.yml b/ansible/file.yml
index 73f6b4d..899610f 100644
--- a/ansible/file.yml
+++ b/ansible/file.yml
@@ -52,7 +52,8 @@
       loop:
-        - "service"
+        - "node_modules"
+        - "systemd_templates"
       
(1/1) Stage this hunk [y,n,q,a,d,e,?]?

А дальше интерактивный ввод. Ну, самое важное — это “y” и “n" — добавить эти изменения в индекс или пропустить. Есть варианты с пропустить или добавить “до конца файла”. Можно использовать как git add -p filename.

Напомню, индекс в git — это список файлов, которые будут закоммичены.

Важно, это действие добавляет наше изменение только в индекс. Его еще нужно закоммитить.

Как еще можно использовать?
#

Как писал вот здесь, я всегда пользовался либо git add ., либо git add <filename>. Но тут есть загвоздка:

при git add . в индекс, а затем и в коммит, могут попасть лишние файлы про редактирование которых ты мог и забыть уже

Вот git add -p позволит более осознанно (преисполненно) пройтись по файлам перед тем как добавить их в индекс.

Так же напомню, что для удаления файла из индекса можно воспользоваться командой git reset filename.

Что я слушаю, когда работаю?

Wed, 07 Feb 2024 00:00:00 +0000

На чем слушаю?
#

AirPods Pro 2 — мощная активная шумоизоляция, отлично держатся в ушах, все еще хорошо держат зарядку, правильно переключаются между девайсами. Им уже больше года, использую каждый день. Я плотно подсел на экосистему Apple и не думаю, что в обозримом будущем уйду к другому бренду наушников.

Что слушаю?
#

Всё очень зависит от настроения, задачи, уровня энергии, но вот основные плейлисты из закладок:

Открытие года — под хип-хоп круто работается, собрал такой плейлист в Spotify. А вот попробовал перенести его в Яндекс.Музыку - ссылка. Очевидно, что не все треки перенеслись, но рекомендательная система должна справиться с наполнением.
Если хочется чуть более спокойной музыки, то включаю lo-fi girl. Либо в Spotify, либо на Youtube.
Вечно угораю с того, что саундтрек от игры Stronghold Crusader второй год подряд оказывается в топе моего Spotify Wrapped, но это не отменяет того, что это очень классный 40-минутный плейлист. Spotify, Youtube.
Длиннющий, одновременно расслабляющий и держащий в фокусе плейлист с ambient-ремиксом саундтрека к фильму Dune.
Тоже длинный плейлист, повторяющийся, но более расслабленный — музыка из игры Witcher 3. Youtube.
Когда настроение повеселее, то могу включить мой retro-плейлист - Spotify, ЯндексМузыка.
Два плейлиста по 15-20 минут — две радиостанции из игры GTA 3 на Youtube: Game Radio, и Head Radio.
Довольно бодрая музыка, может отвлекать, подходит для менее сосредоточенной и рутинной работы — 40 минут, альбом группы The Medics (NL) Spotify, Youtube.

Одинарные и двойные кавычки в Bash?

Thu, 01 Feb 2024 00:00:00 +0000

После информации про фигурные скобки нельзя не сказать про кавычки — где использовать одинарные кавычкиecho 'URL = https://$VAR.ru', а где двойные кавычкиecho "URL = https://$VAR.ru".

Одинарные кавычки (`'some'`):
#

Строки внутри таких кавычек будут считаться буквальными и переменные внутри не будут раскрыты. Все спецсимволы, кроме самой кавычки, трактуются буквально.

VAR=etogeek
echo 'URL = https://$VAR.ru'

URL = https://$VAR.ru

Двойные кавычки (`"some"`):
#

Переменные в строках в таких кавычках будут развернуты:

VAR=etogeek
echo "URL = https://$VAR.ru"

URL = https://etogeek.ru

Обработка спецсимволов:
#

Внутри двойных кавычек некоторые спецсимволы (например, $, \) могут иметь специальное значение и будут интерпретироваться. Например, \n будет заменено на символ новой строки.
Внутри одинарных кавычек спецсимволы трактуются буквально, и они не имеют особого значения.
Спецсимволы можно экранировать (escape) с помощью backslash (\)

VAR=etogeek
echo "URL:\nhttps://$VAR.ru"

URL:
https://etogeek.ru

Тройные кавычки (`"""`, `'''`):
#

Обычно тройные кавычки используются для создания многострочных строк (каламбур, но да). Так же в тройных кавычках можно использовать обычные не экранируя символы:

VAR=etogeek
echo """
This is my site '$VAR':
URL = https://$VAR.ru
Keep learning! "'$VAR'"
"""

This is my site 'etogeek':
URL = https://etogeek.ru
Keep learning! $VAR

🙋‍♂️С комментариями можно смело приходить в наш телеграм-чат.

🌀Так же рекомендую подписаться на телеграм-канал, чтобы не пропускать классные посты и анонсы новых статей.

🎬 А видео выходят на Youtube, канал @etogeek.

В чем разница между $VAR и ${VAR}?

Sun, 28 Jan 2024 00:00:00 +0000

Это реально частый вопрос. Рассказываю в дополнение к посту про подстановку переменных в файл.

Тут нет никакого rocket-science и разница только в том, как командный интерпретатор (Bash, zsh, sh, тысячи их) определит границы названия переменной:

$VAR — хорошо, когда название переменной отделено от другого текста неиспользуемыми символами, например пробелом, или backslash. А вот если переменную вставим в слово, то она будет интепретирована неверно:

VAR=eto
echo $VAR      # Выведет eto
echo $VARgeek  # Выведет значение VARgeek, если такое есть, иначе — пусто

${VAR} — надежнее. Помогает точно отделить название переменной от другого текста:

VAR=eto
echo ${VAR}     # Выведет eto
echo ${VAR}geek # Выведет etogeek

🙋‍♂️С комментариями можно смело приходить в наш телеграм-чат.

🌀Так же рекомендую подписаться на телеграм-канал, чтобы не пропускать классные посты и анонсы новых статей.

🎬 А видео выходят на Youtube, канал @etogeek.

Борьба с продуктивностью. Или за.

Sat, 20 Jan 2024 11:15:16 +0000

Эта статья — объединение двух постов, вышедших в Телеграм-канале. Чтобы не пропускать подобное, подписывайся 💎

⌚️ Привет, друзья! Хочу поделиться своим опытом в борьбе за увеличение продуктивности. Одна из проблем, которую я решаю:

🟠 Сложность в контроле дедлайнов
#

Я могу долго откладывать задачу до последнего момента, или наоборот, могу засидеться с одной задачей и не сделать другую.

С этим мне реально помогает один из методов тайм-менеджмента «calendar blocking». В его основе лежит первый закон Паркинсона:

➡ Работа заполняет время, отпущенное на нее.

Если более простыми словами — мы будем делать задачу ровно столько, сколько на нее отведено времени. Значит нам нужно ограничить время выполнения задачи, поставить ей искусственный дедлайн.

Нашему мозгу гораздо проще сфокусированно работать, когда он понимает, что работа конечна, когда есть четкие временные рамки, ведь через условные 60 минут можно будет переключиться на другую задачу или отдохнуть.

Таким образом, мы можем запланировать день в календаре в виде блоков времени под каждый типа задач, например:

8:00 - 9:00 — Пробуждение, завтрак, зарядка, новости
9:00 - 9:30 — Написать утреннюю часть ежедневной заметки
9:30 - 10:30 — Основная работа
10:30 - 11:00 — Митап с командой
11:00 - 12:00 — Консультация в чате Очень важно менять виды деятельности, эффективнее всего — каждый час. Если ты час писал код, то в следующий блок почитай статью и законспектируй её.

Планирование дней в календаре помогает визуально наблюдать сколько времени тратится на определенные типы задач, структурирует день. Можно группировать задачи: выделить блок на коммуникативные задачи, чтобы сделать их сразу вместе — проверить почту и очистить ящик, актуализировать задачи в спринте, позвонить родителям. Так мы уменьшаем количество переключений контекста.

Не стоит быть слишком жестким по отношению к плану дня. Все мы люди и у всех нас возникают непредвиденные дела или изменения планов — смело двигай тайм-блоки. Если задача не укладывается в тайм-блок — планируй новый, заодно так будет тренироваться умение оценки задач по времени.

🟠 Постоянные отвлечения
#

Некоторым людям сложно сфокусированно работать над чем-то, потому что их мозг постоянно находит способ отвлечься — ссылка в Википедии увела в дебри истории Эритреи, одно уведомление в Телеграме привело к дум-скроллингу по всем каналам, мусор на столе заставляет прибраться.. Да что угодно. Все это заставляет менять контекст, а это мало того, что тормозит прогресс, так еще и выматывает физически.

🍅 Мне действительно в этом помогает метод Pomodoro. Это когда ты работаешь сфокусированно блоками по 20-25 минут, а между ними с чистой совестью отдыхаешь.

☝️ Важно заранее выбрать задачу над которой будешь работать. Не должно быть так, что ты запустил таймер и десять минут выбираешь, чем бы заняться.

Дальше нужно заставить себя работать не отвлекаясь весь этот небольшой блок времени. Сразу после него ты сможешь несколько минут отдыхать — например проверить телегу, размяться, налить чай. Ну, или начать следующий «помидор».

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

Это НЕ серебряная пуля, и это НЕ полностью решает проблему. Но частично помогает мне.

🟢 Как еще можно бороться с отвлечениями?
#

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

Для меня бывает реально сложно проработать полчаса не отвлекаясь ни на что, поэтому я немного меняю схему, начинаю тренировать «выдержку»:

🟠 Ставлю таймер на меньшее время. У меня были даже пятиминутные блоки. Нужно выбрать такое время, которое ты точно сможешь не отвлекаться. Самое сложное — ловить себя на отвлечениях, честно тормозить и сбрасывать таймер.

🟠 Если я понимаю, что хочу и готов проработать следующий блок без перерыва — начинаю его сразу. Со временем временные блоки увеличиваются.

🟠 Вечером я смотрю статистику сколько сфокусированно проработал и делаю выводы. Общую статистику можно обсудить с самим собой на Weekly Review — еще одна техника, которую я хочу попробовать.

🟢 Где следить?
#

Несмотря на огромное количество приложений-таймеров, поиск нужного функционала и подходящего интерфейса чуть не привел меня к написанию своего.. Но, я нашел Tomito. В нем есть все, что мне нужно: статистика, постановка таймера на паузу, виджет «поверх всех окон». Наверное не хватает только мобильного приложения с виджетом для часов.

🔥 Кто-то может обратить внимание и сказать — это же не pomodoro, а обычный таймер. Ну, да ¯(ツ)/¯ Из этого метода по сути я использую только наличие таймера, как дополнительный стимул не отвлекаться. Меня устраивает.

Немного позже у меня будет будет пост-размышление, где я пытаюсь разобраться, что лучше: сфокусированно проработать над крутой задачей или следовать запланированным временным блокам. Stay tuned.

🙋‍♂️С комментариями можно смело приходить в наш телеграм-чат.

🌀Так же рекомендую подписаться на телеграм-канал, чтобы не пропускать классные посты и анонсы новых статей.

🎬 А видео выходят на Youtube, канал @etogeek.

Как создать свой блог на Hugo

Wed, 23 Aug 2023 06:00:29 +0000

Мне кажется, что DevOps — это про творчество. У нас есть огромное количество способов достичь одной цели, и зачастую не будет единственного правильного решения. Что-то более оптимальное, что-то сложнее, что-то удобнее поддерживать.

Мы можем собрать бинарник и положить в контейнер, а можем собрать и закинуть файл по ssh. О, а как запустить — можем просто docker run сделать, а можем завернуть в compose. Или обернуть всё в systemd-сервис, или может в init.d… Ой, а если еще затронуть Kubernetes и Helm…

Мне захотелось на досуге попробовать поднять блог на Hugo. Я раньше это делал, но так нормально и не разобрался с порядком работы. Поднимать буду прямо на виртуалке, сделаю CI/CD пайплайн с разными окружениями и покажу как тестировать все локально.

Что такое Hugo и почему именно он?
#

Hugo — это так называемый генератор статических вебсайтов. Это приложение на языке Go, которое из определенного набора файлов сгенерирует нам статику, а ее мы будем раздавать пользователям с помощью вебсервера.

Классная особенность статических страниц в том, что мы можем раздавать их хоть с s3-бакета, хоть с GitHub Pages.

Почему же именно Hugo? На самом деле генераторов статики несколько: Jekyll, Hugo, Gatsby… Hugo — бесплатный, посты мы готовим в знакомым многим Markdown формате, есть встроенный веб-сервер в не-продакшн режиме… ну и другие я не пробовал.

Выбираем стек
#

Чтобы было повеселее сегодня я сделаю следующее:

Покажу как установить Hugo на виртуальную машину, локально и как запускать его
Настрою Nginx для раздачи статики, добавлю бесплатный SSL сертификат
Установлю self-hosted GitHub Actions Runner на виртуальную машину
Настрою пайплайн со сборкой и доставкой статики на наш сервер

Устанавливаем Hugo на виртуальную машину
#

Тут официальная документация предлагает нам несколько вариантов, вплоть до установки из стандартных репозиториев Ubuntu (apt install hugo), но там устанавливается очень старая версия.

Мы же скачаем .deb пакет и установим его. Идем в репозиторий на GitHub и открываем страницу с последним релизом. Качаем .deb файл с amd64 архитектурой.

# Скачиваем пакет
wget -P /tmp https://github.com/gohugoio/hugo/releases/download/v0.117.0/hugo_extended_0.117.0_linux-amd64.deb

# Устанавливаем пакет
dpkg -i /tmp/hugo_extended_0.117.0_linux-amd64.deb

# Проверяем установку
hugo version

Устанавливаем Hugo локально
#

Параллельно с этим я устанавливаю Hugo себе локально, чтобы было удобнее отлаживать код, а так же чтобы не мучиться с иницализацией репозитория.

Так как у меня MacOS я могу установить Hugo через менеджер пакетов brew:

brew install hugo

Разбираемся как оно работает
#

Эти действия я предлагаю выполнять на своей локальной машине

Для начала создадим структуру для нового сайта. Предположим, что мы у себя в домашней директории:

❯ hugo new site superblog

Congratulations! Your new Hugo site is created in /Users/admin/superblog.

Just a few more steps and you're ready to go:

1. Download a theme into the same-named folder.
   Choose a theme from https://themes.gohugo.io/ or
   create your own with the "hugo new theme <THEMENAME>" command.
2. Perhaps you want to add some content. You can add single files
   with "hugo new <SECTIONNAME>/<FILENAME>.<FORMAT>".
3. Start the built-in live server via "hugo server".

Переходим в созданную директорию и смотрим, что лежит внутри:

❯ cd superblog
❯ tree .
.
├── archetypes
│   └── default.md
├── assets
├── content  <~~ здесь все посты
├── data
├── hugo.toml  <~~ конфигурационный файл сайта
├── layouts
├── static
└── themes  <~~ темы

Теперь нужно установить тему. Повыбирать можно тут, а в качестве примера воспользуемся темой Stack.

Документация предлагает два варианта — установить через git submodules, либо зашить тему вглубь директории layouts (установка через модули Hugo). Первый вариант мне кажется более подходящим — он делает простым смену тем.

Сначала инициализируем git-репозиторий, а затем добавим туда тему как submodule.

git init
git submodule add https://github.com/CaiJimmy/hugo-theme-stack.git themes/stack

И добавим нашу тему в конфигурационный файл:

echo "theme = 'stack'" >> hugo.toml

На этом моменте мы можем уже попробовать запустить Hugo в не-продакшен режиме: в этом случае нам не нужно настраивать Nginx — это очень удобно для локальной отладки нашего сайта и этим мы будем пользоваться постоянно. К тому же оно поддерживает горячее изменение файлов без перезапуска.

❯ hugo server

Watching for changes in /Users/admin/superblog/{archetypes,assets,content,data,layouts,static,themes}
Watching for config changes in /Users/admin/superblog/hugo.toml, /Users/admin/superblog/themes/stack/config.yaml
Start building sites …
hugo v0.117.0-b2f0696cad918fb61420a6aff173eb36662b406e+extended darwin/amd64 BuildDate=2023-08-07T12:49:48Z VendorInfo=brew


                   | EN
-------------------+-----
  Pages            |  7
  Paginator pages  |  0
  Non-page files   |  0
  Static files     |  0
  Processed images |  3
  Aliases          |  3
  Sitemaps         |  1
  Cleaned          |  0

Built in 56 ms
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

Ого, оно что-то сделало и предлагает нам зайти на http://127.0.0.1:1313:

Ну, можно выйти и продолжить: Ctrl-C.

Будем предполагать, что именно таким образом мы будем локально тестировать наш блог: отредактировали, запустили hugo server, посмотрели локально, а затем пушим в репозиторий

Создаем первый пост
#

Общая структура файлов с постами будет следующей:

❯ tree content
content
└── posts <~ общая категория posts, может быть любой другой
    ├── first-post <~ директория под файлы одной статьи
    │   ├── image1.png <~ картинка-аттачмент для первого поста
    │   └── index.md <~ markdown файл первого поста
    └── second-post <~ директория под второй пост
        └── index.md

Перезапустим наш веб-сервер hugo server:

Сейчас нашу статику раздает встроенный веб-сервер hugo. Это так называемый “не-продакшн” режим.

С одной стороны мы можем написать systemd-сервис, который будет запускать команду hugo server. Затем мы можем либо опубликовать этот веб-сервер на 0.0.0.0, либо настроить наш Nginx на обратной проксирование на 127.0.0.1:1313. Но так не было задумано разработчиками.

👉 С помощью команды hugo, приложение сгенерирует статическую версию нашего сайта из всех файлов и положит ее в поддиректорию public.

Установим Github Actions Runner
#

У нас есть возможность хостить наши статические файлы даже в GitHub Pages, и это совершенно несложно. Но не так интересно.

Я буду хостить сайт прямо на виртуальной машине, и Github Actions Runner тоже установлю как self-hosted runner туда же.

Предположим, что мы уже создали отдельный пустой репозиторий в GitHub, к которому мы потом привяжем тот локальный, что мы создавали командой git init.

Переходим в Settings, затем слева Actions - Runners, New self-hosted runner:

Дальше после выбора нужной платформы нам предоставят список команд для установки и инициализации раннера. В конце я рекомендую установить раннер как сервис, для этого можно обратиться к документации, где скажут запустить его командой:

sudo ./svc.sh install

Вот такая картина говорит нам о том, что наш раннер успешно подключился к Github Actions и ждет работы:

Создаем CI/CD пайплайн
#

Документация для референса: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions

Возвращаемся в наш репозиторий, создаем директорию .github, а в ней поддиректорию workflows. Workflows это отдельные пайплайны в Github Actions. Поэтому создаем файл dev-cicd.yml и начинаем творчество. Я сделал так:

name: dev-etogeek cicd
on:
  workflow_dispatch:
  push:
    branches:
      - dev
jobs:
  deploy-dev:
    runs-on: self-hosted
    environment: 
      name: dev
      url: https://dev.mysite.tech
    steps:
      - name: Checkout repo
        uses: actions/checkout@v3
        with:
          submodules: recursive
      - name: Deploy Dev
        run: |
          hugo
          sudo rm -rf /opt/dev-etogeek
          sudo mkdir -p /opt/dev-etogeek/static
          sudo cp -r public/* /opt/dev-etogeek/static/

Теперь по порядку о том, что здесь происходит:

on: workflow_dispatch: — позволяет нам запустить пайплайн вручную, через Run Workflow
on: push: branches: -dev — пайплайн будет запущен автоматически при пуше кода в dev-ветку
runs-on: self-hosted — указывает, где будет запущен наш пайплайн; здесь указываются теги self-hosted раннеров, либо название github-actions образа
environment: — позволит более-менее удобно следить деплоями, не самая обязательная красивость
Этап checkout — склонирует наш репозиторий в рабочую директорию runner-а, а параметр with: submodules: recursive скачает дополнительно нашу тему, которую мы установили как git-submodule. По умолчанию рабочая директория очищается при каждом деплое.

Этап деплоя я сделал таким образом:

Команда hugo генерирует в директорию public статику из нашего hugo-репозитория. Команда, конечно же, требует установленного hugo на виртуальной машине, что мы сделали выше.
Далее мы удаляем директорию с нашей статикой, чтобы каждый раз копировать туда актуальные файлы. Сразу после удаления мы создаем ее заново.
Копируем с ключем -r (recursive) все файлы из директории public в нашу директорию, на которую в будущем будет ссылаться Nginx

Делаем полностью аналогичный файл, только для production-версии нашего блога. Меняем названия, путь к директории и ветку для триггера на main.

Обязательно добавляем в файл .gitignore нашу директорию public:

❯ cat .gitignore
/public/
.hugo_build.lock

Коммитим наш код. Первый раз, думаю, проще будет задеплоиться из основной ветки, чтобы все проверить. А про общий воркфлоу я напишу ниже. Смотрим, что наш пайплайн будет зеленым. Идем на виртуальную машину, проверяем, что все файлы на месте в нужной директории и мы можем приступить к настройке Nginx.

Настройка Nginx
#

На виртуальной машине создаем файл с конфигурацией Nginx /etc/nginx/sites-available/prod.conf:

server {
    server_name mysite.tech;

    root /opt/prod-etogeek/static/;
    index index.html;

    location / {
            try_files $uri $uri/ =404;
    }

    listen 80;

}

Затем создаем symlink в директорию sites-enabled с конфигурациями, которая считывается Nginx-ом:

ln -s /etc/nginx/sites-available/prod.conf /etc/nginx/sites-enabled/prod.conf

Проверяем конфигурацию и перезапускаем Nginx:

nginx -t
systemctl restart nginx
# или systemctl reload nginx

Уже сейчас можем зайти по доменному имени dev.mysite.tech, которое мы конечно же поменяли на свое реальное, и увидим наш сайт. Но, добавить на сайт SSL-сертификат. Нет ничего проще, чем обратиться за помощью к Let’s Encrypt и скрипту certbot:

apt install certbot
certbot

Выбираем наш конфигурационный файл в интерактивном меню, а в конце выбираем Redirect. Можно будет увидеть, что certbot добавил в нашу nginx-конфигурацию несколько новых строк и переадресацию с http на https.

Если и пока у тебя нет доменного имени, можно схитрить и добавить адрес виртуальной машины в локальный /etc/hosts — тогда Nginx будет нормально обрабатывать имя из адресной строки

Процесс работы
#

Основная часть работы позади, автоматизированная доставка кода настроена, стоит подытожить планируемый процесс работы:

Разработку веду в локальном репозитории. Создаю статьи как отдельные .md файлы.
Тестирую работоспособность сайта, визуальную составляющую с помощью встроенного веб-сервера командой hugo server.
Вливаю свою код в dev ветку, спустя минуту-другую наблюдаю изменения на dev-версии блога
Делаю Pull Request из dev-ветки в main-ветку, вливаю его, наблюдаю изменения на production версии блога

Что можно усовершенствовать?
#

Немного размышлений: это сложно назвать прямо идеальным девопсерским ci/cd пайплайном как минимум потому что у нас никак не отделены этапы сборки и выкатки кода.

Мы можем выполнять команду hugo в отдельном этапе, хоть даже на отдельной виртуальной машине или в контейнере. Затем собирать статику в архив, помечать его некой версией, например хэшом коммита и сохранять как артефакт. Затем этот артефакт уносить на dev-машину, и таким же образом — на prod-инстанс.

Но я не уверен, что на текущем этапе мне нужны эти усложнения — я все делаю на одной и той же виртуальной машине, и даже dev и prod окружения у меня лежат просто в соседних директориях. Зачем большее для блога?

Так же мы можем собирать это все не в self-hosted раннере, а в cloud-режиме, который предоставляет GitHub. В конце концов нужно будет просто скопировать собранную статику на нашу виртуалку.

Я писал однажды небольшой пост «Не усложняй» как раз про использование более сложных технологий, чем требует продукт.

🙋‍♂️С комментариями можно смело приходить в наш телеграм-чат — https://t.me/etogeekchat

🌀Так же рекомендую подписаться на телеграм-канал, чтобы не пропускать классные посты и анонсы новых статей — https://t.me/etogeek

Бест-практисы Ansible

Mon, 07 Aug 2023 06:27:19 +0000

В своей текущей работе я очень часто использую Ansible:

раскладываю конфигурации Nginx на серверах,
управляю пользователями
настраиваю серверы
управляю конфигами Hadoop и Solr кластеров
и многое другое.

Это отличный инструмент, который при должном творческом подходе дает прекрасные результаты. Разработчики говорят спасибо, за то что код остается читаемым.

Но не без минусов, конечно. Например, на больших объемах серверов и заданий Ansible становится довольно медлительным и решение подобных проблем становится очень индивидуальной болью. Зачастую приходится переписывать роли, менять порядок выполнения заданий, тюнинговать SSH подключения.

За время работы я сформировал несколько хороших практик, которыми хочу поделиться с вами.

✍️ Используй FQCN
#

- name: Ensure the directory is created
  ansible.builtin.file: <---
    path: /tmp/directory
    state: directory

Модули, которые мы вызываем в Ansible хранятся в коллекциях. FQCN — fully-qualified collection names, это как полное доменное имя, только для модулей ансибла. А точнее оно указывает из какой коллекции взят требуемый модуль.

Ansible сейчас поставляется в двух вариантах, которые мы можем установить:

ansible-core - только исполняемые файлы ansible, дополнительные коллекции ansible community - это ansible-core вместе с пакетом стандартных коллекций, которых чаще всего достаточно для большинства задач. Именно это мы уставливаем при pip install ansible.

Разработчики рекомендуют всегда указывать названия модулей вместе с названиями коллекций для упрощения обращений к документации, соответствию общепринятому стилю кода и.. чтобы ansible-lint не ругался

🗂️ Описывай переменные в host_vars и group_vars
#

Мы часто используем различные переменные. Например, мы можем на уровне инвентори указать, что на сервер gateway-01 мы хотим установить Java версии 8, а на supply01 — Java 11. Или указать нестандартный путь к логам для сервиса sausage-store-backend.

❯ tree inventories/
inventories/
├── group_vars
│   ├── dev.yml        <~ здесь — переменные для группы dev
├── host_vars
│   ├── gateway-01.yml <~ здесь — переменные для конкретных хостов
│   ├── landing-01.yml
│   ├── prod-01.yml
│   ├── supply01.yml
│   └── web-01.yml
└── hosts.yml          <~ здесь — только хосты

Да, мы можем описать переменные прямо в общем inventory-файле. И на это можно закрыть глаза, если у нас всего 2-3 хоста, но это плохая практика, которая сильно усложнит поддержку инвентаря при расширении инфраструктуры.

Так же в group_vars или host_vars можно создать директорию с названием хоста или группы (прямо как в инвентори), а внутрь положить отдельные файлы с переменными, для лучшей организации хранения переменных:

inventories/group_vars/dev/db_settings
inventories/group_vars/dev/cluster_settings

🤔 Помни, что переменные не мержатся, а заменяются
#

В дополнение к предыдущему пункту хочу просто напомнить, что одинаковые переменный из разных файлов не сливаются, а заменяются. Например, у вас есть переменная-список users в файле `group_vars/dev.yml``:

❯ cat inventories/group_vars/dev.yml
users:
  - vpupkin
  - ppetrovic

А рядом лежит такая же переменная, но с другим списком и в другом файле `host_vars/supply01.yml``:

❯ cat inventories/host_vars/supply01.yml
users:
  - iivanov
  - kpomoev

При выполнении заданий на сервере `supply01``, как уже стоило догадаться, они не сольются в единый список из четырех элементов, а будут заменены.

А какой приоритет? От наименьшего к наибольшему:

all group (because it is the ‘parent’ of all other groups)
parent group
child group
host

Финальной переменной будет список из файла host_vars/supply01.yml. Вот раздел документации описывающий это — ссылка.

☢️ Не используй shell и command
#

Основная затея Ansible (как и вообще подхода infrastructure as code) — это описание целевого состояния системы в виде кода. Также Ansible — это про идемпотентность. Это когда повторный запуск задания не принесет никаких изменений, то есть приведет к тому же самому состоянию.

Если мы прокатим наш плейбук второй, третий, десятый, сотый раз — ничего не изменится, потому что мы описали там целевое состояние. Например указали что файл foobar.txt должен присутствовать в директории (state: present), пакет ncdu должен быть установлен, а строка XYZ должна быть в файле /tmp/foobar. Повторный прокат плейбука не создаст нового файла, повторный прокат не добавит новую строку. За этим следят встроенные модули file, copy, lineinfile, apt.

Да, у модулей shell/command есть параметр, который позволяет не выполнять команду, если на сервере, к примеру, есть определенный файл. Но, в целом, они не следят за состоянием системы. Просто выполняют то что сказано. Не приводят к целевому состоянию.

Понятно, что простой shell: ls -lah никому не навредит, но более сложные команды - могут. Вот например запуск скрипта для установки nodejs.. что там делается.. кто будет следить за статусом выполнения…

Старайся максимально избегать использования command и shell модулей на столько на сколько это возможно. Большинство задач можно решить тем, что уже создано для Ansible и будет контролировать состояние задания.

🌚 Не перебарщивай с переменными
#

Есть множество ролей на GitHub, в которых файлы с заданиями буквально на 70% состоят из фигурных скобок и переменных. Это позволяет многие параметры роли сделать настраиваемыми пользователем. Но стоит смотреть правде в глаза — это визуально усложняет поддержку роли, а я уверен, что нужно стараться поддерживать свои инструменты максимально возможно простыми.

🏎️ Тюнингуй ansible.cfg
#

Даже простой тюнинг конфигурационного файла можно довольно сильно ускорить выполнение твоих плейбуков. Только будь осторожен с strategy = free, потому что такой режим позволяет выполнять следующую таску не дожидаясь пока предыдущая выполнится на другом хосте.

Вот пример базового тюнинга конфигурации Ansible.

[defaults]
host_key_checking=False
pipelining = True
strategy = free
ansible_ssh_private_key_file=~/.ssh/id_rsa
ansible_python_interpreter=/usr/bin/python3
callbacks_enabled = timer, profile_tasks, profile_roles
forks = 30

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=60s
retries=3

А вот — документация.

Можно попробовать еще установить плагин Mitogen, который меняет способ взаимодействия Ansible и SSH.

🤐 Никаких кредов в файлах
#

Пользуемся ansible-vault. Он умеет шифровать как целые файлы - удобно для сертификатов, приватных ключей, так и отдельные переменные, которые можно будет вставить в общий файл.

Записываем пароль в файл, а затем выполняем команду, которая зашифрует файл целиком:

ansible-vault encrypt --vault-password-file ~/vault.pass private-key.crt

А можно зашифровать только одну переменную. Вводим команду и передаем ей наш пароль и название переменной:

ansible-vault encrypt_string --vault-password-file ~/vault.pass 'SECRET' --name VARIABLE

s3cmd_secret_key: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          33663339333062616634353663636237396336396434326538316335623062383535393736643937
          3738623538373438373962333631386366623166393934660a363931373165336462633361373835

🕵️‍♂️ Применяй линтер
#

Очень интересные вещи можно узнать про себя просто запустив ansible-lint по всем своим файлам, например:

❯ ansible-lint -p roles
.......
Finished with 305 failure(s), 126 warning(s) on 429 files.

Он тоже настраивается и часть проверок можно отключить.

🧑🏻‍💻Пользуйся handlers
#

Если тебе нужно перезапускать systemd-сервис не нужно делать это при каждом прогоне плейбука. С помощью handlers можно настроить перезапуск сервиса только в определенном случае, например, при изменении конфигурационного файла.

- name: Solr_exporter | daemon-reload
  ansible.builtin.systemd:
    daemon_reload: true

- name: Public_solr_exporter | restart
  ansible.builtin.systemd:
    name: public_solr_exporter
    daemon_reload: true
    state: restarted
    enabled: true

💁‍♂️ Вот такой набор советов получился. Прокомментировать статью, поделиться идеями, поболтать и задать вопрос можно в 👉 телеграм-чате, а так же обязательно подписаться на 👉 телеграм-канал!

Мониторинг SSL сертификатов в Zabbix

Sat, 13 May 2023 20:32:02 +0000

Как можно вообще пропустить дату перевыпуска SSL-сертификата? Пфф, да вообще легко.

Если ты пользуешься certbot, то скорее всего он продляет сертификат автоматически. Но вдруг сломается? Ну или ты забыл при очередном ручном продлении сертификата поставить себе напоминалку.

Короче, нужно настроить мониторинг. В этой статье я покажу как настроить мониторинг SSL сертификатов в Zabbix. А в другой статье я покажу вариант для Prometheus и Grafana. (здесь будет ссылка, когда выйдет вторая статья)

План и схема мониторинга
#

План:

Установить в Zabbix нужный шаблон.
На любой из хостов, которые у нас уже мониторятся установить Zabbix Agent 2.

Схема мониторинга:

У нас есть Host в Zabbix-е, к которому прикреплен Template.
В Host указан адрес реального хоста, с установленным Zabbix Agent 2.
В Template указан адрес веб-сайта, на котором нужно мониторить SSL сертификат.
Zabbix Agent 2 с одного из хостов собирает данные об этом сертификате.

Установить Template
#

Есть вероятность, что у тебя этот шаблон уже установлен, проверь в списке Configuration — Templates. Он в оригинале называется Website certificate by Zabbix agent 2.

Если нет, то его можно скачать и импортировать вручную. (на некоторых скриншотах у меня шаблон переименован, но поверьте — это он) У меня шаблона не было, потому что я ранее обновлял старую версию Zabbix до новой.

👉 Здесь можно взять ссылку на шаблон для нужной тебе версии.

Теперь идем в Zabbix и импортируем шаблон. Заходим в Configuration - Templates и нажимаем Import.

Там выбираем наш файл, нажимаем Import. Всё.

Иногда после нажатия Import может появиться ошибка Invalid tag "/zabbix_export/version": unsupported version number. В таком случае просто в yaml файле шаблона вручную меняем версию на нужную, например - 6.2.

Установка Zabbix Agent 2
#

Установить его можно на любой хост. Именно с него мы будем мониторить наши SSL сертификаты, так что он должен иметь стабильный доступ в интернет.

Для начала хорошо бы выключить старый Zabbix Agent, если он установлен. Я вообще под шумок обновил агенты на всех машинах, заодно во второй версии привезли мониторинг SMART у дисков.

👉 Актуальные и корректные ссылки для установки лучше взять с официального сайта, я лишь приведу ниже пример для Ubuntu 20.04, Zabbix 6.4 на дату выхода статьи:

wget https://repo.zabbix.com/zabbix/6.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.4-1+ubuntu20.04_all.deb

dpkg -i zabbix-release_6.4-1+ubuntu20.04_all.deb

apt update

apt install zabbix-agent2 zabbix-agent2-plugin-*

systemctl restart zabbix-agent2
systemctl enable zabbix-agent2

Добавляем хост для мониторинга
#

Возвращаемся в Zabbix и добавляем новый хост Configuration - Hosts - Create new host:

Затем указываем настройки:

Название хоста любое, но удобнее, если оно будет равно сайту, который мы мониторим
Линкуем наш Template (шаблон)
Добавляем наш хост в Host Group (группа хостов)
Выбираем Add Interface → Agent, указываем адрес (или DNS) хоста с Zabbix Agent 2, откуда мы будем мониторить сайт.

На этом же экране переходим во вкладку Macros, там переходим на вкладку Inherited and host macros, там будут макросы из шаблона. Рядом с макросом {$CERT.WEBSITE.HOSTNAME} нажимаем Change и вводим в поле наш сайт для мониторинга:

Сохраняем хост и идем в Latest Data для проверки:

Меняем порог срабатывания триггера
#

Триггер срабатывает когда срок действия сертификата подходит к концу. Срабатывание триггера основывается на макросе из шаблона. Этот триггер встроен в шаблон.

Как мы можем видеть в меню Templates — Website certificate by Zabbix agent — Triggers наш триггер базируется на некой переменной CERT.EXPIRY.WARN.

Есть две опции как ее поменять — глобально или специфично для хоста:

Глобальная переменная
#

Templates — Website certificate by Zabbix agent — Macros. Таким образом это значение сменится для всех хостов, к которым привязан этот шаблон.

Host-specific macros
#

С помощью этого варианта можно поменять значение для конкретного хоста. Заходим в Configuration - Hosts, находим нужный хост, переходим на вкладку Macros, выбираем Inherited and host macros, нажимаем Change, меняем, ???, PROFIT.

Теперь триггер будет срабатывать на измененное количество дней.

Добавляем поле Days Left
#

Я хотел сделать себе виджет для дашборда, на котором видно сколько дней осталось до конца срока действия сертификата. К сожалению в изначальном шаблоне нет такого поля; только поле с датой окончания. Я решил этот вопрос добавлением _Calculated field _ — это тип item в Zabbix, который рассчитывается на основе других items.

Идем в наш основной шаблон Configuration - Templates - Website certificate by Zabbix agent 2. Там переходим во вкладку Items и нажимаем вверху справа Create Item. Вводим настройки нового Item:

Name: Cert: Days left
Type: Calculated
Key: cert.days_left — ключ нашего item
Type of information: Numeric (float) — у нас будут не целые дни
Formula: round(((last(//cert.not_after) - now()) / 86400),1)
Units: days — считаем в днях
Update interval — любой, у меня 1m — 1 минута

Теперь в Latest Data у нас появился новый Item, по которому мы уже сможем создать Trigger:

Создаем виджет для дашборда
#

Рекомендую заранее объединить наши хоста для мониторинга SSL сертификатов в одну Host Group.

Создадим новый дашборд или добавим виджет на имеющийся.

Переходим в левом меню в Monitoring — Dashboard, нажимаем Create Dashboard.

После ввода имени и других данных (не особо важных) нажимаем Add widget:

Вводим данные как на скриншоте:

To je to! Мы молодцы. 🎉

🙋‍♂️С вопросами и комментариями можно смело приходить в наш телеграм-чат — https://t.me/etogeekchat

Дайджест шортиков — Апрель 2023

Tue, 25 Apr 2023 09:02:08 +0000

Здравствуйте, друзья! Иногда я буду выкладывать подобные посты-дайджесты с крутыми постами из моего Telegram-канала.

Использование .new доменов
#

Мне было сегодня лет, когда я узнал, что:

если ввести в адресной строке браузера doc.new, то откроется создание нового документа в Google Docs.

Еще варианты:🟢 slide.new — презентация🟢 sheet.new — таблица🟢 cal.new — событие в календаре

Да и полный список тут — https://whats.new/shortcuts/

Слишком сложный список задач
#

📖 Одна из причин, почему мы не следуем нашему списку задач или плану на день — в нем слишком сложные задачи.

Мозг реально боится в него заходить и думает «да чего смотреть, там сложные штуки написаны». Конечно, нашему разуму намного проще воспринять и начать делать задачку вроде «назначить синк-встречу с Ваней», чем более абстрактную — «спланировать спринт».

Да, задача со встречей — это всего лишь первый этап большой задачи по планированию, но именно декомпозиция на более мелкие задачи помогает нашему мозгу не бояться списка, а смотреть в него и делать по чуть-чуть.

А если ты делаешь по чуть-чуть, но регулярно, ты достигаешь успеха с перспективе. Это касается как крупных задач, так и привычек.

➡ « Кто не роет, у того нет норки»

Еще, кстати, помогает правильное формирование названия задачи в списке.

Плагин Todoist для Raycast
#

Продолжаем путешествие по плагинам для Raycast.

Кто-то знает, что я все личные и рабочие задачки записываю в Todoist. Конечно же на автомате я установил и плагин для него в Raycast. Честно, так ни разу и не воспользовался, потому что Natural Language нет.

НО затем я нашел команду Menu Bar Tasks. Короче, только ради нее стоит ставить этот плагин:

➡ Todoist Plugin

Команда закидывает иконку Тудуиста в Menu Bar и отображает там нужные тебе задачи, с возможностью управлять. Выглядит симпатично, а главное удобно. Этим мы пользуемся.

Автоматизируй
#

👍 Сегодня железные человечки из дата-центра наконец-то донастроили нам три новых сервера (уф, там неплохое железо). Заказал новые, чтобы проапгрейдить старые. Вот хочу немного верхнеуровнево осветить процесс автоматизации настройки.

И вроде задача несложная:🟢добавить в инфраструктуру и базово настроить несколько новых серверов.

Это могут быть как железные серверы (так называемые bare metal - голое железо), так и свеже созданные виртуальные машины.

Сначала на них надо установить операционную систему. В моем случае сотрудники дата-центра делают это за меня во время настройки и монтажа железа, но когда я учился на мейл-рушном «SRE-квесте» мы практиковались в установке ОС по сети (через PXE), и максимально старались автоматизировать установку через Kickstart.

Для ускорения настройки виртуальных машин можно использовать клонирование машин из некого стандартного образа диска.

PXE — это когда загрузочный образ подключается не как iso с USB, а как набор файлов по сети.Kickstart — это определенный набор скриптов, который позволяет не вводить никакие данные во время установки, а получить стандартизированный настроенный сервер через несколько минут. Короче, автоматическая установка ОС.

Дальше ОС нужно донастроить — создать пользователей, установить базовый необходимый софт, установить агенты для мониторинга. Конечно ты можешь и вручную все сделать, но мы тут не для этого работаем. Простор для творчества огромный, но по сути все сводится к Infrastructure as Code, когда ты в файлах описываешь желаемое состояние твоей системы, а специальный инструмент приводит систему к этому состоянию.

Да-да, Ansible, Puppet, Chef, Salt… вот эти все ребята. Степень автоматизации тоже меняется: у тебя могут быть просто плейбуки, которые ты руками запускаешь для полной настройки, а может быть полный набор ролей или модулей, и в общем манифесте ты указываешь что должно быть установлено и настроено на сервере.

Те же плейбуки могут запускаться и вручную с твоего ноутбука, через Job в Jenkins, через специализированные инструменты вроде Ansible Tower и даже просто в runner после коммита в master-ветку в git.

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

Подобную систему автоматизации установки и настройки серверов довольно сложно и трудозатратно настраивать с нуля, ведь нужно предусмотреть множество факторов: версии ОС, разное железо, сетевые настройки, firewall, разные версии софта… НО, какой же ты получаешь кайф, когда видишь свой первый настроенный «по кнопке» сервер 🔥

➡Автоматизируй.

Guess the game
#

Так, сегодня пятница, поэтому будем угадывать игры 🎮

Как Wordle, только про игры. Осторожно, залипательно!

➡ https://guessthe.game/ Энджой!

p.s. там внизу есть кнопка, чтобы поиграть в “предыдущие дни”.

Не усложняй

Tue, 25 Apr 2023 09:01:04 +0000

🤔 Так ли нужны нам сложные решения?

Всегда ли нужен Кубер в современных проектах? Обязательно ли разворачивать ELK-стек для сбора логов?

Обычно рабочие инструменты не внедряются просто так — они призваны решить какую-то проблему. Нормальный человек не будет настраивать Kubernetes, когда проект еще даже не завернут в контейнеры, аргументируя тем, что это модно. А может Kubernetes в проекте вообще не нужен и достаточно Compose или Swarm? ¯(ツ)/¯

👉 Нужно понимать какой инструмент подходит лучше для решения конкретной проблемы, в чем его плюсы и минусы, насколько «дорогим» выйдет его внедрение.

Причем под дороговизной я понимаю косвенно-финансовую составляющую чего-либо: сколько времени и сил команда потратит на внедрение, обучение, поддержку решения. Человеко-часы тоже платные.

🥲 Один из запомнившихся случаев

В свое время у меня был опыт установки Kubernetes. Ну, на самом деле, не так сложно поднять простой кластер на виртуальных машинах, базово настроить его и задеплоить что-нибудь. И вот на новом месте появилась задача 🟢 динамически запускать тесты на разных машинах.

Совместно с разработчиком собрали в контейнеры эти тесты, которые раньше запускались на специальных виртуалках. Затем я поднял небольшой кластер Kubernetes на виртуалках, просто потому, что я уже умел это делать и это выглядело хорошим решением для оркестрации (управления) контейнерами на разных машинах.

Потратил день, чтобы интегрировать Jenkins с Кубером, затем поразбирался как джобы создавать. Перевел тесты на новую схему, проверил. И знаешь, все отлично работает и по сей день. Тесты теперь гоняются одинаково по времени, нормально распределены по машинам — то что и хотели. 🦾

Только вот не через чур ли сложное решение — поднимать кубер для запуска тестов? Это же виртуалка под мастер-ноду, виртуалки под воркеров. Благо разработчиков не пришлось учить — мы же только тесты запускаем, а это я настраиваю. (привет, бас-фактор 🚌)

А в целом пользоваться им кто-то кроме меня умеет? Контейнерами еще худо бедно многие разработчики умеют пользоваться, а вот Kubernetes зачастую видят в первый раз. Какие там деплойменты, сервисы, ингрессы, вы чего…

И вот другая задача — примерно тоже самое, 🟢 динамически запускать контейнеры на нескольких машинах, иметь возможность горизонтально масштабироваться. Решил попробовать поставить Docker Swarm — ни разу раньше не пользовался 😬.

Оказалось, что кластер инициализируется за минуту одной командой, ноды в него влетают другой командой, а задеплоить сервис можно просто подкинув уже имеющийся docker-compose.yml. Так еще и нет пердолинга с сетью — сервис будет доступен по указанному порту на любой из нод кластера.

Добавил к нему Swarmpit, чтобы кластером можно было управлять из веб-интерфейса.

Крутим там сейчас сервисы, которые иногда требуют масштабирования — все отлично работает. Разработчикам проще — есть веб-интерфейс, это более понятные «просто контейнеры», еще и docker-compose синтаксис. Затрат на поддержку меньше.

Следующий этап 🟠 выпилить к чертям Kubernetes, о котором тут речь, и поднять на его месте свежий Swarm-кластер. Заодно попробую Portainer для удобного взаимодействия с кластером, вместо Swarmpit.

Подумай, а так ли тебе нужен сложный комплексный инструмент, когда можно обойтись более простым?

Сканер открытых портов в Raycast

Thu, 30 Mar 2023 18:30:12 +0000

В этой статьей я покажу, как можно добавить свой скрипт в Raycast на примере проверки открытых портов на серверах.

Я очень часто пользуюсь сервисами для проверки открытых портов на серверах, чтобы быстро понять закрыт ли у меня определенный порт на сервере или нет. Для этого в закладках держал вот этот сайт https://www.yougetsignal.com/tools/open-ports/ (один из многих, на которых можно проверять порты)

Не так давно писал про Raycast как замену для Alfred, и про то, что я довольно быстро разобрался как добавить свой скрипт в быстрый запуск. Собственно, даже упоминал этот скрипт в том посте, но хочу рассказать чуть подробнее.

В общем, так как мне нравится тот сайт, я посмотрел через «консоль разработчика» какой запрос делается в момент нажатия на кнопку Check.

Создаем скрипт
#

Оставалось только немного поэкспериментировать с параметрами curl запроса и получился такой:

curl -s -X POST https://ports.yougetsignal.com/check-port.php\?remoteAddress\=$1\&portNumber\=$2

$1 и $2 это аргументы, которые были переданы .sh скрипту при запуске (например scripts.sh foo bar. $1 = foo, $2 = bar и так далее. $0 это всегда название файла)

Нам остается только «выцепить» Open или Closed из ответа. Делаю через grep -o "Open\|Closed". Параметр -o выведет только ту строку, которая матчится с регуляркой, а у нас там «или Open или Closed».

Объединяю две команды (curl и grep) через пайп (символ |). Пайп (pipeline) переводит стандартный вывод (stdout) первой команды на стандартный ввод (stdin) второй.

Добавляем эту команду в наш .sh файл, не забывая шебанг #!/bin/bash.

Добавляем скрипт в Raycast
#

Но, что сделать, чтобы Raycast «увидел» наш скрипт?

Нужно добавить некоторую мета-информацию — название, поля для интерактивного ввода, документацию… Внимательнее можно посмотреть на нее в моем скрипте, должно быть все понятно. Или в официальных примерах.

Затем заходим в настройки Raycast (Cmd + ,).

Открываем вкладку Extensions, ищем там пункт Script Command (через поиск почему-то не находится) и нажимаем на него. Справа будет Add directories, в ней и добавляем директорию с нашим скриптом.

Сразу вешаем на него какой-нибудь короткий Alias:

Если добавить новые скрипты в эту директорию, то они автоматически появятся в Raycast. Максимум — нужно будет запустить команду Reload Script Directories.

Теперь пробуем запустить:

Единственное с чем я не заморачивался — это цвет «лампочки» внизу — он базируется на коде ответа скрипта, поэтому всегда зеленый, если curl был успешен.

Как видишь, добавить свой скрипт в Raycast совсем не сложно. Главное, чтобы была фантазия.

Ты можешь скачать мой репозиторий со скриптами и добавить его по инструкции из README. Вот ссылка 👉 https://github.com/etoosamoe/raycast-scripts

А подписавшись на мой телеграм-канал ты точно не пропустишь новые статьи и интересности из интернета ✌️

Split DNS в MacOS, OpenVPN и Tunnelblick

Wed, 29 Mar 2023 08:34:18 +0000

В этой статье речь идет исключительно о настройке доступа к внутреннему рабочему защищенному сетевому контуру инфрастркутуры.

В этой статье я покажу как можно настроить Split DNS в MacOS, и как изменить конфигурацию Tunnelblick, чтобы автоматически включать Split DNS при подключении к OpenVPN серверу.

Split DNS — это возможность отправлять DNS запросы для определенной зоны на определенные DNS серверы.

👉 Пример использования, с которым столкнулся я
#

Есть OpenVPN сервер и есть DNS серверы во внутреннем сетевом контуре, которые обслуживают две доменные зоны foobar.com и .bar.

Зона foobar.com обслуживается как внутренними DNS-серверами, так и внешними (Cloudflare). Это сделано, чтобы иметь “внутри” приватные DNS записи, но с “реальными” доменными именами.

Мы хотим при подключении VPN начинать использовать внутренние DNS, а при отключении возвращаться обратно. Но мы не хотим при подключенном VPN отправлять все DNS запросы на внутренние серверы.

❗ Изменение настроек OpenVPN сервера
#

Так как мы будем управлять «раздачей» DNS серверов с помощью Tunnelblick, то нам нужно убрать (убедиться, что этого нет) push DNS серверов из конфигурации OpenVPN сервера.

За это отвечают следующие инструкции в конфигурации, проверяем, что их нет:

root@server01.bar /home/admin # cat /etc/openvpn/openvpn.conf | grep dhcp
push "dhcp-option DNS 35.36.37.0"
push "dhcp-option DNS 35.36.37.1"
push "dhcp-option DOMAIN bar"

🌐 Настройка resolvers в MacOS
#

Введя команду scutil --dns мы можем увидеть список текущих резолверов:

❯ scutil --dns

resolver #1
  nameserver[0] : 192.168.31.1
  if_index : 8 (en0)
  flags    : Request A records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)

...

Это основной текущий резолвер, которой отправляет все DNS запросы на один DNS сервер (мой маршрутизатор).

Мы можем насоздавать своих резолверов путем создания файла /etc/resolver/foobar.com, с точным именем доменной зоны и адресами DNS серверов внутри:

❯ cat /etc/resolver/foobar.com
nameserver 35.36.37.0
nameserver 35.36.37.1

Снова проверяем резолверы. Теперь все DNS запросы для этой зоны пойдут на внутренние серверы, а остальные — как и было раньше через основной резолвер:

❯ scutil --dns

...

resolver #8
  domain   : foobar.com
  nameserver[0] : 35.36.37.0
  nameserver[1] : 35.36.37.1
  flags    : Request A records
  reach    : 0x00000002 (Reachable)

🌀 Настройка Tunnelblick
#

Чтобы добавлять резолверы автоматически при подключении VPN и удалять при отключении, нам нужно добавить скрипты в конфигурацию Tunnelblick.

🔹 Создаем отдельную директорию mkdir vpn, а в ней файл скрипта, который будет запускаться при подключении VPN

nano connected.sh

#!/bin/bash -e

mkdir -p /etc/resolver

cat <<EOF > /etc/resolver/foobar.com
nameserver 35.36.37.0
nameserver 35.36.37.1
EOF

cat <<EOF > /etc/resolver/bar
nameserver 35.36.37.0
nameserver 35.36.37.1
EOF

🔹 Создаем скрипт, который будет запускаться при отключении VPN nano post-disconnect.sh:

#!/bin/bash -e

rm /etc/resolver/foobar.com
rm /etc/resolver/bar

Эти скрипты будут запускаться от пользователя root, если не указано обратное в конфигурации. Документация по скриптам есть на оф. сайте.

🔹 Добавляем в директорию файл с .ovpn конфигурацией. Предполагается, что мы ее уже имеем.

🔹 Делаем скрипты исполняемыми:

chmod +x connected.sh post-disconnect.sh

🔹 Переименовываем, а точнее добавляем к названию директории расширение .tblk. У нас получается файл vpn.tblk, на который можно нажать правым кликом и посмотреть содержимое Show Package Contents.

🔹 Перетаскиваем файл vpn.tblk мышкой на иконку Tunnelblick в Menu Bar (наверху). Таким образом мы добавляем новую конфигурацию в Tunnelblick. Разработчики обращают внимание именно на этот способ — им виднее.

🔹 Подтверждаем несколько раз, что готовы к вероятности наличия fork-бомбы или rm -rf в скриптах, и пробуем подключиться. После успешного подключения проверяем наличие новых резолверов, а так же успешные ping до внутренних DNS.

Важно: проверка DNS записи через dig выдаст ошибку NXDOMAIN, потому что dig использует другой механизм резолва адресов.

🙌 Дополнительно
#

Обычно я в настройках Tunnelblick-а дополнительно включаю перезапуск сетевых интерфейсов, для большей стабильности работы интернета при засыпании ноутбука и отключениях VPN:

На этом всё 🤝 Если тебе понравилась статья, рекомендую подписаться на телеграм-канал, где анонсятся все новые статьи, а так же выходят интересные посты. Ссылка ниже:

@etogeek

Как практиковаться начинающему DevOps-инженеру

Sat, 25 Mar 2023 17:28:03 +0000

«Я учусь на DevOps-а, но как мне практиковаться?»

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

В этой статье я подготовил небольшой роад-мап или список задач, по которым ты можешь получить начальный опыт. А если ты уже работаешь с чем-то, то попрактиковаться с новыми инструментами. Он довольно универсальный, поэтому в каждый пункт можно сильно углубляться.

Напоминание один: Старайся конспектировать каждый этап. Все действия и команды. Поверь, это пригодится. Я обращался к своим записям бесчисленное количество раз.

Напоминание два: На каждом этапе пытайся разобраться, а что изменится, если ты выберешь другой инструмент. Какие плюсы и минусы будут? Например, Gitlab CI или Jenkins, Ansible или Puppet, Zabbix или Prometheus.

У меня был микро-конспект видео с канала Techworld with Nana про изучение новых инструментов и технологий — 👉 пост в телеграм-канале.

Вот пример задач, в каждой из которых можно найти множество подводных камней, решение которых и даст тебе заветный опыт. Расставлены в порядке увеличения сложности:

🖥️ Создать виртуальную машину — это можно сделать как на своем компьютере/ноутбуке, так и создать в каком-нибудь облаке. Некоторые облачные провайдеры дают бесплатный период — это удобно для обучения. В первом случае мы еще и научимся базово устанавливать Linux.

🔑 Разобраться с настройкой ОС, установкой пакетов, научиться настраивать SSH и подключаться к серверу с помощью ключей.

🗯️ Найти несложный проект на Github, который ты будешь препарировать. Лучше, если это будет приложение, которое можно «повесить» на какой-нибудь порт, и оно будет что-то отдавать. Хотя бы {”status”: “ok”} или html-страничку с Hello World. Например, мой — писал о нем в телеграм-канале.

Язык на котором написан сервис не особо важен — что тебе больше нравится. Во многих курсах используется Java. Вероятно потому, что в Java у тебя будет выделенный этап сборки твоего кода в .jar файл с помощью какого-нибудь Maven или Gradle. В Python, например, такого не будет. Я бы рекомендовал начать с Java, просто чтобы лучше ознакомиться с процессом.

Искать можно по запросам типа «simple python web application». Например:

https://gitlab.com/devops-bootcamp3 — тут целая подборка на разных языках
https://github.com/noqcks/java-hello-world-api — что-нибудь подобное
https://medium.com/@ismailvohra/how-to-create-a-simple-hello-world-rest-api-in-spring-boot-a89e75cbb48b — можно и свой написать :)

🖐️ Попробовать запустить этот сервис руками на виртуальной машине. То есть нам нужно скачать репозиторий с кодом, собрать приложение и запустить его.

🛠️ Когда у нас сформировался список действий, которые нужно сделать для разворачивания приложения — можно описать это все в Ansible.

🧑🏻‍💻 Добавить к приложению systemd-сервис, чтобы его было проще запускать и контролировать его работу. Разобраться с автозапуском, переменными окружения. Узнать какие еще бывают системы инициализации.

🤖 Автоматизировать деплой проекта — сделать репозиторий в Gitlab или GitHub, установить self-hosted runner и по документации набросать пайплайн сборки и запуска приложения. Можно вообще развернуть Jenkins и поизучать его, заодно понять разницу между этими инструментами.

📦 Наконец, написать Dockerfile и собрать приложение в контейнер. Разобраться как его запускать, пробрасывать порты, переменные, как подключать директории с виртуалки в контейнер. Изучить бест-практисы создания образов контейнеров, понять разницу между CMD и ENTRYPOINT.

🚚 Научиться загружать образы контейнеров в Docker Hub. А затем начать использовать приватные Container Registry: поднять свой, или использовать тот, что есть в Gitlab. Есть еще и крупные «комбайны» типа Nexus, Artifactory.

⛴️ Посмотреть на Docker Compose, разобраться зачем он нужен и как нам может помочь. Попробовать развернуть приложение через compose.

🌎 Установить Nginx, настроить reverse proxy для приложения. Понять как работает и получить SSL сертификат. Автоматизировать конфигурацию можно с помощью Ansible, который, кстати, тоже можно запускать из Github/Jenkins.

🔥 Установить Zabbix или Prometheus + Grafana (вместо Prometheus можно поставить Victoria Metrics). Настроить мониторинг виртуальной машины — процессора, оперативки, места на дисках, научиться отслеживать доступность приложения, сделать удобный дашборд.

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

Когда это уже давно пройдено можно переключиться на Advanced уровень:

🪵 Поднять ELK-стэк (а может быть Loki?) и настроить сбор логов приложения для более удобного просмотра.

☁️ Развернуть и настроить виртуальные машины в облаке с помощью Terraform. В дополнение можно использовать Packer и Ansible.

❤️‍🔥 Развернуть приложение в Kubernetes. Начать можно с minikube — такой кубер на минималках для локальной машины. Изучить основы и структуру Kubernetes.

В общем, вариантов много. Теоретические знания из статей и видео нужно обязательно закреплять на практике, и если в реальной работе у тебя таких задач нет, то можно максимально приблизиться к реальности вот на таких примерах.

🤔 «И что мне с этим делать потом? Что говорить на собсеседованиях?»

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

во-вторых, на собеседовании намного лучше сказать «у меня нет продакшн опыта с этим инструментом, но я изучал его самостоятельно, знаю чем он отличается от X и Y, и что даст его внедрение. вот я делал A и B во время изучения»

💡 Рекомендую подписаться на телеграм-канал, чтобы не пропускать новые посты и интересную информацию.

Миграция Grafana из SQLite в PostgreSQL

Tue, 07 Mar 2023 19:00:17 +0000

Иногда может случиться так, что Grafana перестает показывать графики, показывает в веб-интерфейсе ошибки. Зайдя в логи сервиса ты можешь увидеть частые сообщения:

error="database is locked"

Что за ошибка?
#

Опишу так, как это понял я.

По умолчанию Grafana использует в качестве базы данных файл SQLite, и все было бы хорошо, если бы не версия 8.0.0, в которой разработчики перелопатили систему alert-ов. При увеличении количества настроенных алертов база данных может не справляться с нагрузкой и блокироваться.

Даже разработчики подтверждают такую проблему:

Первое решение, временное
#

Скорее всего первое, что тебе попадется в Google по этому запросу, это статья в community Графаны с советом забекапить SQLite базу данных в новый файл, поменять их местами и перезапустить Графану.

sqlite3 grafana.db '.clone grafana-new.db'
mv grafana.db grafana-old.db
mv grafana-new.db grafana.db

Такое приходилось делать, когда внезапно перезагружаешь контейнер или машину с графаной. И оно действительно работает.

Но спустя пару месяцев наши разработчики решили добавить десяток алертов, что привело к не выходящей из состояния блокировки базы данных.

Пришлось прибегнуть к

Второе решение, постоянное
#

Это переехать на другую базу данных. Выбираем PostgreSQL.

В моем случае Grafana развернута в контейнере с помощью docker-compose, таким образом мы просто развернем рядом еще один контейнер с базой данных. Но есть проблема, мы же хотим сначала перенести SQLite БД в PostgreSQL.

Поднимаем контейнер с PostgreSQL 13, подключаем к нему директорию, в которой он будет хранить данные. Я сделаю это с помощью docker-compose.

Создаю директорию для хранения данных:

mkdir -p /var/lib/postgresql/data

Можно также воспользоваться docker volume.

Создаю docker-compose.yml:

version: '3.9'

services:
  postgres:
    image: postgres:13.10-alpine3.17
    restart: always
    container_name: postgres-grafana
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=superstrongpassword
    ports:
      - '127.0.0.1:5432:5432'
    volumes: 
      - /var/lib/postgresql/data:/var/lib/postgresql/data

Запускаю его:

docker-compose up -d

Зайдем в PostgreSQL и создадим новую БД:

docker exec -ti postgres-grafana /bin/sh
psql
CREATE DATABASE grafana;

Теперь нам нужно создать в базе данных таблицы с нужными схемами данных. Для этого мы запустим Grafana и подключим ее к свежей базе. Потом выключим. Добавляю в docker-compose.yml новый сервис:

grafana:
    image: grafana/grafana:version
    container_name: grafana
    user: "2017"
    volumes:
      - /var/lib/grafana:/var/lib/grafana
    environment:
      GF_DATABASE_TYPE: postgres
      GF_DATABASE_HOST: postgres:5432
      GF_DATABASE_NAME: grafana
      GF_DATABASE_USER: postgres
      GF_DATABASE_PASSWORD: superstrongpassword
      GF_DATABASE_SSL_MODE: disable
    ports:
      - 3000:3000

Запускаем и мониторим логи, дожидаясь завершения миграций:

docker logs -f grafana

После того, как миграции закончатся, можно выключить Grafana и приступить к переносу БД SQLite в PostgreSQL.

docker-compose stop grafana

Перенос с помощью pgloader
#

Ориентировался я на статью.

TL;DR у меня не получилось

Первым делом я решил воспользоваться утилитой pgloader, которую можно установить из стандартных репозиториев:

apt install pgloader

Disclaimer: именно из-за pgloader пришлось разворачивать PostgreSQL 13, а не 14. Дело в том, что в 14 версии начали использовать метод шифрования паролей по умолчанию scram-sha-256 вместо md5. pgloader не умеет с ним работать. Можно изменить, но это лишние действия.

Создаю файл-скрипт для переноса БД:

load database
  from sqlite:///var/lib/grafana.db
  into postgresql://postgres:superstrongpassword@127.0.0.1/grafana
  with data only, reset sequences
  set work_mem to '16MB', maintenance_work_mem to '512 MB';

Запускаем утилиту:

pgloader script.load

По идее, после этого должно все работать. Но нет. У меня перестала работать авторизация. После логина выбрасывало обратно на ввод логина/пароля.

Перенос с помощью grafana-migrate
#

Как я смог понять проблему — Grafana записывает некоторые значения в БД в виде hex, что не очень хорошо переносится в PostgreSQL с помощью pgloader.

grafana-migrate — это самописная утилита, которая лежит в github https://github.com/wbh1/grafana-sqlite-to-postgres

Disclaimer: если перед этим ты делал что-то с базой через pgloader, то лучше будет удалить БД, создать снова и провести миграции.

Скачиваем бинарник с утилитой:

wget https://github.com/wbh1/grafana-sqlite-to-postgres/releases/download/v2.2.3/grafana-migrate_linux_amd64-v2.2.3

Формируем команду и запускаем утилиту:

./grafana-migrate /var/lib/grafana/grafana.db 'postgres://postgres:superstrongpassword@127.0.0.1:5432/grafana?sslmode=disable'

Здесь возникает подводный камень:

У меня grafana.db весит 150 мегабайт.

На сервере с HDD дисками процедура миграции БД не закончилась за 12 часов.
На сервере с SSD дисками это было быстрее, но я не стал ждать дольше часа.
На сервере с nvme диском эта процедура заняла чуть меньше 30 минут.

После этого я просто перенес директорию с данными /var/lib/postgresql/data с “быстрого” сервера на другой, где должна была крутиться Grafana.

Полезности
#

Давай доформируем окончательно наш docker-compose.yml файл:

version: '3.9'

services:
  postgres:
    image: postgres:13.10-alpine3.17
    restart: always
    container_name: postgres-grafana
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=superstrongpassword
    ports:
      - '127.0.0.1:5432:5432'
    volumes: 
      - /var/lib/postgresql/data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5
  grafana:
    image: grafana/grafana:9.0.4
    container_name: grafana
    user: "2017"
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - /var/lib/grafana:/var/lib/grafana
    environment:
      GF_DATABASE_TYPE: postgres
      GF_DATABASE_HOST: postgres:5432
      GF_DATABASE_NAME: grafana
      GF_DATABASE_USER: postgres
      GF_DATABASE_PASSWORD: superstrongpassword
      GF_DATABASE_SSL_MODE: disable
    ports:
      - 127.0.0.1:3000:3000

Я добавил healthcheck для сервиса postgres, который раз в 5 секунд проверяет, доступна ли база данных. Это удобно на этапе запуска:

если Grafana запустится до того, как запустится postgres - возникнет ошибка. Параметр depends_on будет ждать, пока сервис postgres не перейдет в состояние healthy.

Так же я закрепил контейнер с Grafana за интерфейсом 127.0.0.1. У меня уже настроен Nginx reverse proxy, который будет проксировать запросы извне, на 127.0.0.1:3000 - в Grafana.

🌈 Надеюсь, тебе понравилась статья. Рекомендую подписаться на канал в Телеграме, чтобы не пропускать полезную информацию:

👉 Телеграм канал

Не перебивай!

Tue, 28 Feb 2023 08:51:09 +0000

Небольшая история про один из важнейших софт-скиллов. Или как сказали некоторые в телеграм-канале “ты бы еще сказал, что нужно штаны снимать в туалете”. Это база, но не все замечают за собой такие проблемы.

Года три назад после одного из совещаний ко мне подошел наш рекрутер и сказал, что перебивать технического директора не стоит. Как, собственно, и других людей во время разговора в принципе.

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

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

➡ Не перебивать — один из важнейших софт-скиллов любого человека. Это базовое уважение к твоему собеседнику.

Попробуй переложить ситуацию на себя — ты рассказываешь историю, а тебя перебивают или вставляют свои реплики в твою речь. Меня бы это выбесило очень быстро.

Именно то замечание как будто открыло мне глаза на весь масштаб ситуации — я не осознавая того перебивал СТО в разговоре (вопрос субординации тут не поднимаю, у всех все по-разному).

К сожалению, я не нашел какой-то серебряной пули от этой проблемы — только самоконтроль. Ты сам можешь этого не замечать — можно договориться с близкими или друзьями, чтобы они обращали твое внимание, когда ты перебиваешь кого-то. Я сделал именно так.

Если ты думаешь с чего бы начать прокачивание софт-скиллов — начни с анализа своего поведения в диалогах. Поставь себя на место собеседника.

Вот здесь можно подписаться на новые посты, а так же комментировать их.

История про принтеры

Wed, 15 Feb 2023 17:50:16 +0000

Году так в 2016 я работал в фармацевтической компании. Это был первый день, а точнее первые сутки, когда я перешел с должности оператора техподдержки, на позицию саппорта. Мы работали сутки-трое и мне предстояла вполне стандартная ночка — переустановить винду пару раз, следить чтобы ничего не упало, а если упадет — звонить кому нужно.

Специфика работы компании такова, что по ночам на складе кипит работа сильнее, чем днем — там собираются заказы, которые утром поедут в аптеки. К каждому заказу должен быть напечатан комплект документов. Для этого был даже специальный отдел “распечатка”, где стояли несколько огромных принтеров Riso.

Это такие бандуры, больше двух метров в длину, которые умеют печатать порядка 120 полноцветных страниц в минуту, а если нужно, в конце может скреплять документы, как степлером. Но в таком случае, простите, только 60 в минуту 😭

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

На меня, видящего эти принтеры первый раз в жизни, смотрят неодобрительно и шутят (или нет), что сейчас сам сяду скреплять бумажки степлером. Я пооткрывал крышки, попротирал датчики — стандартная процедура. Коллега, который хоть немного шарит в этих машинах, уже разбужен и советует попробовать поменять блоки степлирования местами и осмотреть их визуально. meh.

В кабинет начинают стекаться местные работники со степлерами в руках, принтер, с которым я не ковыряюсь запускают в обычном режиме — степлировать будут вручную. Мой коллега уже вызвал такси и едет на работу, чтобы спасать мне жизнь.

К утру удалось оживить только один из двух сломанных “степлеров”, а местные рабочие действительно сидели и вручную скрепляли листы бумаги. Инженер из сервисной компании уже вызван, и должен приехать в этот же день. Мы сидим в кабинете, упиваемся кофем, ждем начала рабочего дня. Слушаю истории из жизни в компании. До нового года оставалось 5 дней.

Хорошее время, вспоминаю его с теплотой.

👉 Телеграм-канал — @ etogeek

Итоги 2022 года

Mon, 09 Jan 2023 20:59:42 +0000

Подвожу итоги прошедшего 2022 года, пусть туда и катится.

Горизонт планирования уменьшился до нескольких недель, а в худшее время — до нескольких часов.

☕️ купил кофемашинку — капсульная nespresso vertuo — крутая. А потом капсулы перестали продавать ¯_(ツ)_/¯

🌍 окончательно решил для себя, что буду эмигрировать в другую страну — всё

🤡 купил тысячу долларов по 120 — «а вдруг дороже будет»

👷‍♂️ сменил работу — теперь занимаюсь даже двумя проектами, значительно увеличил доход

🚘 2000 км за рулем — впервые проехал от Москвы до Орска с остановкой в Набережных Челнах

🌊 покатался на сапе — взял у друзей, интересно

🏕️ пожил в глэмпинге в Карелии — уехали в глушь на машине с собакой, Тусили в огромной сафари-палатке. Очень холодно. Жена чуть ногу не сломала. Но красиво.

🇬🇧 занимался английским — три месяца, регулярно. Очень пригодилось.

🧵 написал тред в твиттере — первый, который разлетелся на 700+ лайков. Это про ведение дневника. Приятно.

🚜 улетел в Турцию без обратного билета — а потом в Сербию

😢 продали машину — вроде ничего особенного, но машина была в кредите и продавалась по доверенности. Я-то был в другой стране. А машину жалко.

🚙 поездил на машине в другой стране — взял в аренду в Анталии

🎮 купил Nintendo Switch — уж очень портативная и удобная штука. Игры дорогие только.

🙋‍♀️ человек года — моя дорогая жена, которая поддерживала меня во всем каждый день

🎶 музыка года — Zola Blood - The Only Thing, Amesoeurs - Amesoeurs, Arctic Monkeys - Four Out Of Five

🔥 самое яркое событие — уехал жить в другую страну. Незапланированно.

Итоги 2021 года — тут.

Apache Airflow: деплой DAG файлов из git

Sat, 12 Nov 2022 13:11:39 +0000

У меня в опыте три развертывания Apache Airflow в продакшн, и я ни разу не находил в Гугле способа хранить DAG-файлы в git и деплоить их в Airflow. Пришлось изобретать свой.

Цель
#

Дать возможность разработчикам редактировать DAG-файлы, зависимости и т.д. локально на своих компьютерах, пушить код в git-репозиторий, и через несколько минут получать эти изменения в Airflow.

Так же передо мной стояла задача хранить конфигурацию Apache Airflow в git.

Дисклаймер

В этой статье я не рассматриваю способы тестирования DAG-файлов перед выкаткой на прод, хотя это очень важно.
У Airflow есть документация, в которой описаны различные best practices, включая способы тестирования.

Условия
#

У меня установлен Apache Airflow согласно прекрасной документации. В моем случае я не использую Airflow в Docker, а запускаю его на виртуальной машине через systemd.

Что нужно
#

git-репозиторий в котором мы будем хранить наш код и пайплайн
CI/CD система (GitLab CI, GitHub Actions, Drone CI, тысячи их)
Настроенный runner для вашей CI/CD системы
Установленный Ansible, вместе с модулем ansible.posix.synchronize на машине с runner-ом, и установленный rsync на обоих машинах

Готовим репозиторий
#

Создал директорию dags. В ней я храню все DAG-и, дополнительные файлы, например, скрипты. Вообще что угодно — это всё будет деплоиться в наш инстанс Airflow.

Создал в корне репозитория файлы:

connections.json — здесь мы храним необходимые подключения для Airflow в следующем виде:

{
    "test_connection": {
        "conn_type": "postgres",
        "description": "Тестовая БД",
        "host": "localhost",
        "login": "dev_ro",
        "password": "super_password",
        "schema": "mark",
        "port": 5432,
        "extra": "{\"cursor\": \"dictcursor\"}"
      }
}

requirements.txt — зависимости для Python, которые нужны для запуска DAG-ов. Записываю в стандартном для Python виде:

apache-airflow-providers-postgres==2.0.0
pytz==2021.1
pytzdata==2020.1

variables.json — переменные, которые Airflow будет использовать в работе:

{
  "my_var": "test",
  "your_var": "hello"
}

Еще один дисклаймер:

я не рассматриваю сейчас способы хранения sensitive data в переменных и подключениях. Для этого нужно использовать немного другой способ. Например — шифровать файлы с помощью Ansible Vault.

airflow.cfg — конфигурация Apache Airflow. По умолчанию можно записать данные из актуального файла /etc/airflow/airflow.cfg

Плейбук
#

Деплой я настроил с помощью любимого Ansible.

В корневой директории репозитория создал директорию ansible, а в ней файл ansible.cfg:

[defaults]
host_key_checking=False
ansible_ssh_private_key_file=~/.ssh/id_rsa
ansible_python_interpreter=/usr/bin/python3
callbacks_enabled = profile_tasks
forks = 25

Там же создал файл hosts.yml и в нем указал мой хост с Airflow:

all:
  children:
    airflow:
      hosts:
        airflow.your.domain:

Теперь переходим к нашему плейбуку. У меня на сайте есть несколько статей по базовому Ansible, рекомендую посмотреть: первая статья, вторая статья.

Создал файл playbook.yml и начал заполнять:

- name: Airflow deploy playbook
  hosts: airflow
  gather_facts: false
  become: true

  vars:
    src_path: ".."
    dst_path: /etc/airflow
    airflow_home_env:
      AIRFLOW_HOME: /etc/airflow

DAG
#

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

# SYNC
    - name: Sync DAGs directory
      ansible.posix.synchronize:
        src: '{{ src_path }}/dags/'
        dest: '{{ dst_path }}/dags/'
        delete: true
        recursive: true
      tags:
        - sync
        
    - name: Change files permissions
      ansible.builtin.file:
        path: '{{ dst_path }}'
        state: directory
        recurse: true
        owner: airflow
        group: airflow
      tags:
        - sync

Опишу что тут происходит. В первом таске я использую модуль ansible.posix.sychronize, который под капотом запускает rsync. Синхронизирую директорию ../dags в директории с репозиторием и директорию /etc/airflow/dags на машине с Airflow.

Я указываю директиву delete: true, чтобы удалять те файлы, что были удалены из репозитория, и директиву recursive: true, чтобы синхронизировать так же директории внутри dags.

Во втором таске я проставляю корректные права на файлы.

Зависимости
#

# Install requirements
    - name: Copy requirements.txt file
      ansible.builtin.copy:
        src: "{{ src_path }}/requirements.txt"
        dest: "{{ dst_path }}/"
        owner: airflow
        group: airflow
        mode: 0775
      tags:
        - requirements
        
    - name: Install requirements python modules
      ansible.builtin.pip:
        requirements: "{{ dst_path }}/requirements.txt"
      tags:
        - requirements
      register: pip_output
      become_user: airflow
      
    - name: Print install output
      ansible.builtin.debug:
        var: pip_output.stdout_lines
      tags:
        - requirements

В этом блоке я копирую файл с зависимостями, запускаю его установку и вывожу результат.

Переменные
#

# Import variables
    - name: Copy variables.json file
      ansible.builtin.copy:
        src: "{{ src_path }}/variables.json"
        dest: "{{ dst_path }}/"
        owner: airflow
        group: airflow
        mode: 0775
      tags:
        - variables
        
    - name: Import variables
      ansible.builtin.shell:
        cmd: /home/airflow/.local/bin/airflow variables import variables.json
        chdir: '{{ dst_path }}'
      become_user: airflow
      tags:
        - variables
      environment: "{{ airflow_home_env }}"
      register: variables_import_output
      
    - name: Print variables import output
      ansible.builtin.debug:
        var: variables_import_output.stdout_lines
      tags:
        - variables

Первым делом я, уже стандартно, копирую файл с переменными. Затем совершенно некрасивый, но необходимый этап — bashsinble — запускаю команду импорта переменных, указывая chdir, пользователя airflow и переменной AIRFLOW_HOME.

Подключения
#

Импорт подключений выглядит абсолютно так же как и импорт переменных. Меняется только тэг и команда.

Деплой в GitHub Actions
#

В GHA мы храним пайплайны(workflows) в директории .github/workflows. У меня она выглядит так:

> tree .github
.github
└── workflows
    ├── airflow_cfg.yml
    ├── connections.yml
    ├── dags.yml
    ├── requirements.yml
    └── variables.yml

Разделил все на отдельные файлы, чтобы была возможность запускать их по отдельности вручную, если понадобится. Что в dags.yml:

name: Deploy DAG files

on:
  workflow_dispatch:
  push:
    branches:
      - master
    paths:
      - 'dags/**'
  
jobs:
  sync-dags:
    runs-on: self-hosted
    steps:
      - name: Checkout repo
        uses: actions/checkout@v3
      - name: Run Common playbook
        env:
          PY_COLORS: '1'
          ANSIBLE_FORCE_COLOR: '1'
        run: |
          cd ansible && \
          ansible-playbook -i hosts.yml airflow-deploy.yml \
          --tags sync

Разберу по частям:

workflow_dispatch: позволяет запускать пайплайны вручную из меню Actions, а так же запускать их не из master ветки.
branch: master и paths: запустит пайплайн только в случае коммита в master ветку и при изменении в указанных файлах
jobs: указываю, что запускаться мы будем на self-hosted раннерах. Запускаю модуль Checkout для скачивания репозитория и запускаю плейбук с определенным тегом.
env: передаю несколько переменных, например для включения цветного вывода в GitHub

Остальные workflows выглядят абсолютно так же, меняется только название, директория в paths: и тэг в ansible.

Так же у меня в репозиторий добавлен скрипт для уведомлений о деплоях в Slack, который я вызываю после выполнения плейбука в зависимости от результата:

      - name: Send OK branch notify
        if: ${{ github.ref != 'refs/heads/master' && success() }}
        run: python3 notify.py deploy_branch
        
      - name: Send OK notify
        if: ${{ github.ref == 'refs/heads/master' && success() }}
        run: python3 notify.py deploy_ok
        
      - name: Send FAIL notify
        if: failure()
        run: python3 notify.py deploy_failed

Итог
#

Airflow периодически проверяет наличие новых файлов и изменения в старых. Интервал проверки настраивается в конфигурационном файле.

Теперь я могу запускать пайплайны вручную из вкладки Actions:

Разработчики коммитят код в ветки, делают Pull Requests, ревьювят свой код. Все довольны.

📱 Оставить комментарий к посту или задать любой вопрос ты можешь в моем Telegram-канале:

@etogeek

🇬🇧English version on Medium.

Как ведение дневника помогает моей продуктивности

Thu, 15 Sep 2022 10:33:11 +0000

Не очень нравится само название «дневник», мне намного больше импонирует английское journaling. Одна из лучших техник-находок этого года, хотя сама техника, конечно же, не нова.

Главный совет — веди дневник. Каждый день, хотя бы несколько осмысленных предложений. Пиши вечером о вчерашнем дне, или утром про вчерашний день.

Как делаю я?
#

Пишу заметку и утром и вечером. Стараюсь писать менее сухо, как будто пишу пост в телеграм-канал.

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

Затем пишу краткий план на день и хайлайт — центральную задачу, которая доставит мне радость, приблизит меня к цели или просто будет очень полезной.

Как придумать хайлайт?
#

Представь, что за день ты можешь делать только одну единственную задачу. Странно, конечно, но попробуй. Что бы это было?

🎮 «Час поиграть в Геншин». Почему нет, ведь это доставит мне удовольствие, и заодно отвлекусь от рабочих мыслей.

📱 «Позвонить маме». Отлично, мама будет рада.

🤵🏻‍♂️ «Сделать сборочный пайплайн для приложения». Всегда приятно, когда работает то, что ты сделал.

Например, вчера у меня был записан хайлайт «сделать ревью статьи про journaling».

Вечером подвожу итоги на горячую голову. Теперь можно дать волю эмоциям, высказаться о задачах, пожарах, мыслях, которые меня беспокоят. Оставляю небольшой план на следующий день, вроде «а завтра надо бы доделать эту задачу».

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

Зачем вести дневник?
#

🧘 Такое ежедневное написание заметок помогает рефлексировать — в процессе создания короткой заметки фокусируешься на своих ощущениях и мыслях. Это тренировка осознанности. В первые пару дней я не мог выдавить из себя даже три предложения и писал что-то вроде “я поел, завтра тоже поем”. Теперь я начал записывать свои мысли более обширно, и замечаю это как раз благодаря регулярным заметкам.

📈 Трекинг прогресса — если чему-то учишься или двигаешься к цели, будет очень полезно в эти заметки включать какой-либо маркер прогресса продвижения к твоей цели. Например “сегодня разобрался как собирать java-приложение, это большое продвижение по моему ci/cd роад-мапу”.

✍️ Ты учишься писать — чтобы научиться что-то делать, нужно делать это каждый день. Вот и пиши, по чуть-чуть и каждый день. Представь, что в процессе написания простой ежедневной заметки у тебя появится огненная мысль, которая со временем превратится в крутую статью.

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

Где вести журнал?
#

Основное различие будет - цифровой или физический. Или оба?

📓 Бумажный дневник я вести не пробовал — мне слишком жалко время, и боюсь, что очень быстро забью на эту привычку. Очевидно, что на письмо от руки тратится больше времени и за это время будет много отвлечений.

Но! Во многих статьях и книгах говорят о том, что записывание своих мыслей на бумагу помогает еще лучше в них разобраться. Если ты лучше воспринимаешь информацию визуализируя — стоит попробовать.

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

Я пишу ежедневные заметки уже около месяца прямо в Notion. Сделал database-табличку, и добавил view в виде календаря, чтобы видеть, какие дни пропустил. Заметил, что по выходным обычно забываю сделать заметку, потому что меньше сижу за ноутбуком.

Веду дневник уже месяц и могу заверить, что это помогает мне собрать мысли в кучу, проанализировать день и сделать выводы. Начинают проскакивать мысли «Хм, свободная минутка, почему бы не написать пару строк в дневник» Рекомендую.

👉 А ты пробовал вести дневник? Прокомментировать ты можешь в Телеграм-канале. Подпишись и не пропускай новые статьи.

Перенос git репозитория

Thu, 18 Aug 2022 06:55:30 +0000

Небольшой набор команд для переноса одного git репозитория в другой. Я, например, пользовался при переносе из Github в Gitlab.

git clone --bare git@git.test.com:my-repo-a.git
cd my-repo-a.git
git fetch origin
git remote add new-origin git@git.test.com:my-repo-b.git
git push --mirror new-origin
git remote rm origin
git remote rename new-origin origin

Давай разберем команды:

git clone --bare — клонируем не сам репозиторий, а директорию .git

git fetch origin — убеждаемся, что у нас все изменения присутствуют

git remote add — добавляем новый remote репозиторий

git push --mirror new-origin — загружаем весь наш репозиторий в новый. mirror передает все refs — тэги, бранчи

git remote rm — удаляем старый origin локально

git remote rename — переименовываем new-origin в origin, чтобы было проще работать

Комментарии можно оставить в уютном чате 👉 https://t.me/etogeekchat

А больше гайдов и новостей выходит в канале 👉 https://t.me/etogeek

Как посмотреть внешний IP в Linux

Tue, 16 Aug 2022 10:06:32 +0000

Мне часто нужно узнать с какого IP адреса я выхожу в интернет.

Конечно, мы можем зайти на какой-нибудь сайт, вроде myip.ru и посмотреть, но как быть, когда ты работаешь на сервере?

В терминале пользуюсь регулярно:

curl ifconfig.so

В ответ получим наш внешний ip-адрес. И всё.

Но, начав работать с некоторыми облачными провайдерами заметил, что такой запрос может возвращать “серый” адрес, вроде:

rnd-1:~$ curl ifconfig.so
172.20.4.1

Тогда можно использовать один из многих других сайтов, например:

curl ifconfig.me

В браузере можно воспользоваться теми же сайтами, они дадут более даже подробную информацию:

Кстати, можно так же воспользоваться утилитой dig, например, когда на сервере нет установленного curl:

dig ip @dns.toys

Но это скорее из разряда прикольных вещей — https://www.dns.toys/

👉 Больше шортиков выходит у меня в Telegram-канале: https://t.me/etogeek

caffeinate — macbook, не спи

Sun, 14 Aug 2022 12:48:01 +0000

На MacOS есть встроенная программа для того, чтобы система не уходила в сон.

Запускается из терминала простой командой:

caffeinate -t 3600

Параметр -t и количество секунд устанавливает время бодрствования устройства. 3600 секунд = час.

Но вот беда — терминал нельзя закрывать. Об этом в конце.

Параметры
#

-t — количество секунд

-d — не выключать экран

-i — не переводить истему в idle режим

-s — не давать засыпать системе, когда комп подключен к питанию

-u — имитирует поведение пользователя

-w PID — можно указать process id, чтобы программа завершилась после завершения процесса. Например:

caffeinate -disu -t 13453

Зачем использую?
#

Пару раз я скачивал что-то очень большое, не хотел прерывать загрузку. Ну, и при засыпании прерываются ssh-сессии, помогает, чтобы не перезаходить потом. VPN не обрывает соединение.

Минусы
#

Терминал нельзя закрывать. Да, мы можем добавить амперсанд & в конец команды, чтобы она запустился в фоне, тогда мы сможем продолжить использовать эту терминальную сессию. Но закрыть — нет.

Еще я пользуюсь комбайном для MacOS — Alfred. Там стоит workflow для включения caffeinate режима. Тык-тык две клавиши, написал caff 2h и пошел по своим делам.

Так же можно использовать одно из многих приложений, которое крутится в трее и запускает caffeinate, например:

https://apps.apple.com/ru/app/owly-prevent-display-sleep

👉 Больше шортиков выходит у меня в Telegram-канале: https://t.me/etogeek

Дейлики

Mon, 01 Aug 2022 15:32:38 +0000

Они же митапы, синки.

Да, я про ежедневные встречи с командой. Во времена удаленки и распределенных команд они проводятся онлайн.

Меня поражают люди, которые направо и налево кричат «на кой черт нам эти митапы, только отвлекают от работы»

Ну да, ну да. Занят ты, конечно. Вообще, это реально нужно и полезно. Команда, если, конечно, у вас принята командная работа, а не «каждый сам за себя» должна знать, чем ты занимаешься.

Это занимает от силы 15 минут в день в зависимости от размера команды, всегда в одно время. Говорить надо и того меньше — минуту-две: чем занимался, чем будешь заниматься, какие блокеры были.

Основная цель — прозрачность работы команды, обменяться статусами по задачам и проекту в целом.

На моем предыдущем месте работы дейлики длились по часу-полтора. Это выглядело так: пять разработчиков, три девопса, один куа. Каждый рассказывает с чем столкнулся вчера, но в отличие от классического скрам-дейлика лид начинает досконально разбирать каждую проблему вплоть до непосредственного фикса в прямом эфире.

По началу это было интересно — лид смешно шутил, но через пяток дней я понял, что это какая-то дичь и надо по-быстрому рассказывать, мьютиться и заниматься своими задачами.

На текущей работе дейлик длится от 10 до 20 минут. В случае если кто-то начинает углубляться в проблему звучит фраза “давай это вынесем в отдельную встречу или в чат”. Всё. Идеально.

Синкапы нужны, кто бы что не говорил. Они помогают поддерживать актуальное понимание того, чем занята команда. Минимум воды, максимум полезности. Удачи!

👉 Больше шортиков выходит у меня в Telegram-канале: https://t.me/etogeek

Краткие итоги 2021 года

Sat, 01 Jan 2022 08:30:00 +0000

Все подводят итоги года и я подведу. Полноценную статью не успеваю закончить.

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

🔧 Сменил должность на текущей работе — стало проще

🐕 Купили собаку — взрыв мозга

🎉 Нашли топовых друзей — еще и соседи

✍️ Создал блог и не забросил его через месяц — но подзабросил через три

🤵‍♂️ Женил лучшего друга — первый раз на чужой свадьбе

🧗 Начал заниматься скалолазанием — главное не падать

🏞 Съездили в Сочи и Турцию — нужно отдыхать

🏜 Пережили жару и чуть не похоронили кота — сраное лето

💻 Купил макбук — лучшее приобретение

🏎 Купил новую машину — привет, китаец

👨‍🚀 Сменил работу спустя пять лет — ну наконец-то

🏗 Купил первый Лего — Юра, почти тридцать лет, здравствуйте

Поздравляю всех с наступающим новым годом! Пусть все ваши желания сбудутся!🎄

Кто не роет, у того нет норки

Thu, 19 Aug 2021 10:18:12 +0000

Когда я читал «Джедайские техники» Дорофеева, почему-то пропустил целый блок про закон хомячка. Осознав то, что мне пытался донести автор, меня, можно сказать, осенило.

Если вкратце, то автор рекомендует двигаться к целям маленькими кусочками, по чуть-чуть, но постоянно.

В моем понимании нужно разбить задачу на такие маленькие части, чтобы ты мог их сделать за один присест. Например, когда у тебя возникает 15-минутный перерыв между встречами. Обычно в такое время мы ожидаем следующей встречи и ничего не делаем, хотя можем взять задачу из плана на день и сделать небольшой кусочек от нее, а затем переформулировать её суть с учетом уже сделанного.

Небольшой пример:

У меня была запланирована задача «Составить список баз данных в инфраструктуре». Зачем — не столь важно. Задача муторная, неинтересная, довольно долгая и поэтому браться за нее не хочется.

Но вчера в течение дня я несколько раз брался за неё небольшими отрывками по 10-30 минут, и уже к вечеру задача была выполнена почти на 75%. Если бы я не заставлял себя «делать по чуть-чуть», то она так бы и переносилась в планах на следующий день.

Ты, вероятно, часто встречал упоминание этого метода в различных формулировках: пиши статьи каждый день, хотя бы по паре предложений; отжимайся хотя бы пару раз в день. В общем:

Делай по чуть-чуть, не откладывай на потом.

Привыканием к этому я и собираюсь заняться в ближайшие несколько недель.

Увеличение разделов в Linux на горячую

Thu, 06 May 2021 06:33:17 +0000

Частая задача в моей текущей работе — увеличить объем раздела на виртуальной машине без выключения машины (на горячую). Под рукой постоянно держу небольшой cheatsheet (шпаргалку) по работе с разделами в Linux.

План действий
#

Перед изменением размеров разделов рекомендуется отмонтировать диск. Если диск системный, то нужно загружаться в recovery. Я делаю это на горячую на свой страх и риск.

Делаем бекап машины! (не могу не написать этого)
Увеличиваем объем диска в гипервизоре (этот пункт не затрагиваем)
Сканируем диски в системе
Меняем размер раздела
Увеличиваем файловую систему

Сканируем диски в системе
#

После увеличения объема диска есть вероятность того, что в системе мы новый объем сразу не увидим. Проверяем. Я использую команду lsblk:

root@hostname.infra.local:/home/user# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
fd0      2:0    1     4K  0 disk
loop0    7:0    0  99,2M  1 loop /snap/core/10908
loop2    7:2    0  99,2M  1 loop /snap/core/10958
sda      8:0    0    32G  0 disk
├─sda1   8:1    0     1M  0 part
└─sda2   8:2    0    32G  0 part /
sdb      8:16   0     4T  0 disk            <<<--------
└─sdb1   8:17   0     4T  0 part /pgsqldb   <<<--------
sdc      8:32   0 109,8G  0 disk
└─sdc1   8:33   0 109,8G  0 part /temp_dump
sr0     11:0    1   829M  0 rom

Стрелкой я выделил диск, который мы увеличили до 5Т, но увеличенный объем не видим.

Нужно заставить систему просканировать диск.

echo 1 > /sys/block/sdb/device/rescan

(вместо sdb - нужный диск)

Сразу после этого снова выполняем lsblk:

sdb      8:16   0     5T  0 disk
└─sdb1   8:17   0     4T  0 part /pgsqldb

То что нужно. Перейдем к увеличению раздела.

Меняем размер раздела
#

Вообще, мы можем для любых вариантов использовать программу parted, но я покажу еще способ с программой fdisk. Он подходит для разделов объемом менее 4 терабайт.

Здесь будет несколько вариантов:

у нас обычная разметка диска или LVM
у нас диск c таблицей разметки GPT более 4 терабайт объемом

Рекомендую на этом этапе сначала выполнить команду parted -l, которая может показать ошибку и предложить опции Fix\\Ignore:

Warning: Not all of the space available to /dev/sdb appears to be used, you can fix the GPT to use all of the space (an extra 41943040 blocks) or continue with the
current setting?
Fix/Ignore? Fix

Пишем Fix .

Обычные разделы или LVM
#

Чаще всего я пользуюсь программой fdisk. Можно посмотреть все наши диски\разделы: fdisk -l.

Так как меняем размер раздела на диске sdb, то и заходим в fdisk /dev/sdb.

Вводим команду p и получаем наш текущий список разделов:

Device     Start        End    Sectors Size Type
/dev/sdb1   2048 8589843750 8589841703   4T Linux filesystem

Удаляем раздел /dev/sdb1: вводим команду d.

Command (m for help): d
Selected partition 1
Partition 1 has been deleted.

Если разделов на диске больше, программа предложит ввести цифру нужного раздела.

Никаких изменений на диск мы еще не сделали! Не боимся.

Создаем новый раздел n:

Command (m for help): n
Partition number (1-128, default 1):
First sector (34-8589934558, default 2048):
Last sector, +sectors or +size{K,M,G,T,P} (2048-8589934558, default 8589934558):

Created a new partition 1 of type 'Linux filesystem' and of size 4 TiB.

Обратите внимание, программа сообщает, что при создании раздела она нашла запись ext4 в разделе и предлагает удалить ее. Не удаляем. Нет! Не надо!

Partition #1 contains a ext4 signature.
Do you want to remove the signature? [Y]es/[N]o: N

Опять вводим команду p, чтобы посмотреть новую информацию:

Device     Start         End     Sectors Size Type
/dev/sdb1   2048 10751953125 10751951078   5T Linux filesystem

Ну вроде все хорошо. Теперь вводим команду w (write). После этого ваши изменения запишутся на диск.

Большой диск GPT
#

Если по предыдущему пункту попробовать отресайзить диск большого объема (больше 4 терабайт), то появится ошибка Value out of range. Придется воспользоваться программой parted.

Делаем parted /dev/sdb и смотрим текущие разделы командой print:

(parted) print
Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 4398GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  3299GB  3299GB  ext4         primary

Меняем размер раздела командой resizepart 1:

(parted) resizepart 1
Warning: Partition /dev/sdb1 is being used. Are you sure you want to continue?
Yes/No? Yes
End?  [3299GB]? 4398GB

На вопрос End? пишем новый объем раздела. Если хотим расширить его до максимума, то цифры можно подсмотреть выше в выводе команды print: Disk /dev/sdb: 4398GB

Здесь изменения происходят сразу, поэтому при отсутствии вывода после предыдущей команды можно делать quit.

Увеличение файловой системы
#

Тут должно быть все просто. Разница только между разметками: обычная или LVM.

Обычная разметка
#

Просто выполняем команду resize2fs /dev/sdb1:

root@hostname.infra.local:/home/user# resize2fs /dev/sdb1
resize2fs 1.44.1 (24-Mar-2018)
Filesystem at /dev/sdb1 is mounted on /pgsqldb; on-line resizing required
old_desc_blocks = 384, new_desc_blocks = 512
The filesystem on /dev/sdb1 is now 1073730212 (4k) blocks long.

LVM
#

Вообще, LVM позволяет добавлять физические диски (PV - physical volume) в VG - volume group, а в них создавать логические тома (LV - logical volume) примерно по такой схеме:

sda1     sda2     sdb     sdc       <-- PV
 |        |        |       |
 |        |        |       |
 +--------+- VG00 -+-------+        <-- VG
              |
 +-------+-------+---------+
 |       |       |         |
root    usr     home      var       <-- LV
 |       |       |         | 
ext3 reiserfs reiserfs    xfs       <-- Файловые системы

Следовательно, можно не ресайзить диск в гипервизоре, а добавить еще один. Затем добавить новый PV в VG.

Но мы идем путем джедая увеличения диска, поэтому в случае с LVM к ресайзингу файловой системы добавляется несколько команд.

Для просмотра информации о PV, VG, LV существуют команды pvs, vgs, lvs. И их более подробные варианты pvscan, vgscan, lvscan:

root@hostname:/home/user# pvs
  PV         VG            Fmt  Attr PSize  PFree
  /dev/sda5  t-ubuntu16-vg lvm2 a--  49.52g    0
root@hostname:/home/user# vgs
  VG            #PV #LV #SN Attr   VSize  VFree
  t-ubuntu16-vg   1   2   0 wz--n- 49.52g    0
root@hostname:/home/user# lvs
  LV     VG            Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root   t-ubuntu16-vg -wi-ao---- 48.52g
  swap_1 t-ubuntu16-vg -wi-ao----  1.00g

Меняем размер PV pvresize /dev/sda1
Увеличиваем размер LV до максимального lvextend -l +100%FREE /dev/mapper/vg1-dsads-lv-root
Увеличиваем файловую систему на нужном разделе resize2fs /dev/mapper/vg1-dsads-lv-root

Итог
#

Смотрим, что у нас получилось df -h:

root@hostname.infra.local:/home/user# df -h
Filesystem                                Size  Used Avail Use% Mounted on
udev                                       38G     0   38G   0% /dev
tmpfs                                     7,5G  4,4M  7,5G   1% /run
/dev/sda2                                  32G   24G  6,3G  79% /
/dev/sdb1                                 5,0T  3,3T  1,5T  71% /pgsqldb <<<-----

Видим новый объем. Все счастливы и довольны.

TL;DR
#

Кратко cheatsheet у меня выглядит так:

Смотрим, видит ли система новое место на дисках: lsblk, parted -l, fdisk -l

Если не видит: echo 1 > /sys/block/sda/device/rescan (вместо sda - нужный диск) fdisk /dev/sda (if sda)

p - просмотр разделов

d - удалить раздел который расширяешь

n - создать новый раздел (создастся с тем индексом, который удалишь)

В большинстве случаев везде ответы будут по умолчанию. Когда спросит про затирание метки - НЕ удалять

p - проверить что разделы имеют тот же вид что и в начале

w - записать изменения на диск

resize2fs /dev/sda1 (номер - индекс раздела)

Если LVM:

pvresize /dev/sda1

lvextend -l +100%FREE /dev/mapper/vg1-dsads-lv-root

resize2fs /dev/mapper/vg1-dsads-lv-root

Если ошибка с gpt

parted -l → Fix

💡 Подписывайтесь на Телеграм-канал, чтобы не пропускать новые статьи

Телеграм канал 📺
Чат 🤘🏼

Индивидуальные презентации в IT-отделе

Tue, 20 Apr 2021 21:00:00 +0000

Некоторое время назад я закидывал свои мысли по поводу корпоративных презентаций в свой Телеграм-канал, а сейчас хочу выложить на сайт.

В марте этого года наш Head of IT решил привнести в работу АйТи-департамента что-то новенькое — общие митапы по итогам квартала и планированию следующего.

Часть таких митапов проходила в формате индивидуальных выступлений каждого сотрудника, где он рассказывал о своих достижениях и работе за первый квартал 2021 года. Подавляющему большинству сотрудников эта затея не понравилась и меня это расстраивает.

Немного истории
#

Когда я пришел в эту компанию чуть больше пяти лет назад, весь IT-департамент состоял из 20 человек: три админа, три-четыре саппорта, пару руководителей, хэд-оф-айти (другой), и десяток-полтора 1С-программистов и пару бизнес-консультантов вместе с ними. Бизнес-консультант — это современный продакт (ПМ).

Сейчас численность департамента больше 120 человек. Количество проектов выросло в разы, число групп и отделов возросло вместе с ними.

Как было анонсировано
#

Вам необходимо подготовить презентацию Вашей индивидуальной работы в 1 кв. (квартал — прим. автора): выполненные задачи, достижения, анализ показателей. Каждое выступление в эти 2 дня будет длиться 10 минут: 7 минут - само выступление и 3 минуты - вопросы.При подготовке выступления просим воспользовался шаблоном презентации, который был разослан всем 19 марта.

Что было после анонса
#

Когда всем разослали анонс митапа с индивидуальными выступлениями всех сотрудников, работа отдела встала минут на 40. Постоянно звучали фразы “да зачем это надо”, “а работать кто будет”, “че за бред”, “а можно не участвовать?”. Следующее подобное бурление началось за 1-2 дня до митапа.

Что было на митапе
#

Конечно, все подготовили презентации, за исключением парочки залетных. Но 95% презентаций состояли из слайда со списком технических задач, который зачитывался с экрана и дополнялся импровизированным текстом.

65% не уложились в 7 минут из-за того, что зацикливались на нескольких пунктах и долго рассказывали про них. Я слушал не все выступления, но те, что смог в большинстве своем были скучными. И богатыми на технические термины - не дай бог подключится кто-нибудь, кто не знает, что такое RAID5 или черри-пик.

Как следовало анонсировать (ИМХО)
#

Основная задача — рассказать для чего проводятся подобные митинги. Для этого я привел выше небольшую историческую справку. У нас большой АйТи отдел, в котором много людей, включая удаленных сотрудников. Далеко не все знают, чем занимается соседний отдел или даже соседняя команда.

Важно знать с чем и как работают твои коллеги.

Как следовало готовиться (ИМХО)
#

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

А еще — это развитие софт-скиллов (публичные выступления).

Очень надеюсь, что по итогам следующего квартала коллеги будут делать более интересные презентации. Постараюсь кому смогу донести важность этого мероприятия.

Полезные ссылки
#

Выступление про мониторинг — выступление про мониторинг. Но здесь важен формат подачи: классная презентация, нескучный текст.
Подкаст про публичные выступления - подкаст от Линкмиап про подготовку к публичным выступлениям.

💡 Если вам нравятся мои посты, то подписывайтесь также:

Новостной канал 📺
Чат 🤘🏼

Перенос базы Postgresql на другой диск

Thu, 01 Apr 2021 21:00:00 +0000

Жил был сервис, и была у него база, и жила она в /var/lib/postgresql на основном диске. И стала база занимать почти весь диск.

Ну и мы не лыком шиты, перенесем ее на отдельный диск.

План такой:

Добавляем новый диск
Монтируем его в какую-то папку
Переносим туда БД
Тут, возможно, мы захотим жить в новой директории - тогда поменяем конфиг.
Прячем текущую папку /var/lib/postgresql
Монтируем наш диск вместо старой папки

Погнали 🚀

Готовим диск
#

Представим, что мы уже добавили диск в гипервизоре и видим его в выводе lsblk:

admin@host.infra.domain.local:~$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0    7:0    0 99.2M  1 loop /snap/core/10908
loop1    7:1    0 99.2M  1 loop /snap/core/10859
sda      8:0    0  550G  0 disk 
├─sda1   8:1    0    1M  0 part 
└─sda2   8:2    0  550G  0 part /
sdb      8:16   0 1000G  0 disk <<<<------- THIS

Теперь разметим его с помощью parted:

parted /dev/sdb
mklabel gpt
unit s
mkpart primary ext4 0% 100%
quit

Отформатируем раздел в ext4:

mkfs.ext /dev/sdb1

Монтируем диск
#

Сначала создадим левую папку, куда мы примонтируем новый раздел и будем перекидывать базу mkdir /tempdb.

☝️ Хорошим тоном считается добавлять в /etc/fstab записи с UUID диска, а не /dev/sdb1.

Дальше посмотрим UUID нашего раздела. Даем команду blkid:

/dev/sda2: UUID="b651b0ae-ef1d-11e9-be07-005056926860" TYPE="ext4" PARTUUID="1cd39f87-c0cd-f24d-baff-a39ff152be09"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/sdb1: UUID="fe561baa-f4de-4c52-bdff-cc496353a0a9" TYPE="ext4" PARTLABEL="primary" PARTUUID="4d0987b3-0010-434c-aac4-b42ba2a75582"

Вот же он: /dev/sdb1: UUID="fe561baa-f4de-4c52-bdff-cc496353a0a9"

Теперь добавляем строку в файл /etc/fstab, можно руками через vi/nano, можно echo-м:

echo 'UUID=fe561baa-f4de-4c52-bdff-cc496353a0a9 /tempdb ext4 defaults 0 0' >> /etc/fstab

После этого делаем mount -a. Раздел примонтирован в новую папку.

Перенос базы
#

Сначала остановим сервис systemctl stop postgresql, чтобы во время копирования не записывались свежие данные.

Начинаем копировать данные:

rsync -arv /var/lib/postgres/ /tempdb

и ждем. У меня база на 500Гб копировалась два часа, но всё зависит от железа, самой базы, фазы луны и дня недели.

На этом этапе мы можем изменить путь к базе в конфигурационном файле postgresql и запустить сервис, всё будет работать. Для этого редактируем файл /etc/postgres/10/main/postgresql.conf и меняем пусть к директории в строке:

data_directory = '/tempdb/10/main'

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

mkdir /var/oldpostgres && mv /var/lib/postgres/ /var/oldpostgres

Теперь проверим, что мы не напутали с папками и /var/lib/postgresql на месте. Если нет - mkdir /var/lib/postgresql.

Размонтируем диск umount /tembdb, а затем заходим в nano /etc/fstab и редактируем строку с подключением. Нам нужно изменить точку монтирования. Должно получиться так:

UUID=fe561baa-f4de-4c52-bdff-cc496353a0a9 /var/lib/postgresql ext4 defaults 0 0

☝️ Не забудь, что UUID у тебя будет свой уникальный

Делаем mount -a и пробуем запустить сервис systemctl start postgresql.

Проверяем
#

Как проверить? Ну например netstat -tulpn | grep 5432, и если у вас постгрес на стандартном порту, должен быть вывод, вроде:

tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN      225199/postgres     
tcp6       0      0 :::5432                 :::*                    LISTEN      225199/postgres

Можно попробовать зайди в базу sudo -u postgres psql:

psql (10.16 (Ubuntu 10.16-0ubuntu0.18.04.1))
Type "help" for help.

postgres=#

Если всё ок, можно удалить старую базу, чтобы освободить место в корне.

💡 Если вам нравятся мои посты, то подписывайтесь также:

Новостной канал 📺
Чат 🤘🏼

Бекапы индексов в Elasticsearch

Tue, 02 Mar 2021 21:00:00 +0000

👌 Ты заходишь в Кибану, а там ничего нет.

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

Причиной этого является, скорее всего, скоропостижная кончина системного индекса .kibana, в котором хранятся все ее настройки.

Люди делятся на два типа: те, кто еще не делает бекапы и те, кто уже делает бекапы

Бекапы индексов
#

Вот мы сейчас и научимся делать бекапы\снапшоты индексов

Ссылка на официальную документацию вот: https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html, но я попробую сделать саммари.

Что нужно сделать
#

добавить директорию как репозиторий для хранения снапшотов на машины с эластикой
настроить бекапы в новый репозиторий
????
PROFIT

Добавить директорию
#

Предположим, что у нас уже смонтирована какая-нибудь сетевая шара как директория /mnt/bck01. Подключение к шаре выполняется с помощью программы cifs-utils и запись в /etc/fstab выглядит так:

//<server_hostname>/BackupServers$/LinuxServers/kibana /mnt/bck01 cifs user,rw,credentials=/root/.smbclient,iocharset=utf8,uid=elasticsearch,gid=elasticsearch,file_mode=0775,dir_mode=0775 0 0

Подробнее про подключение сетевых шар в другой статье.

Нужно добавить эту директорию в настройки Elasticsearch. Идем в /etc/elasticsearch/elasticsearch.yml и добавляем:

path:
  repo:
    - /mnt/bck01

Сохраняем файл и делаем:

systemctl restart elasticsearch

💡 Добавлять в конфигурацию путь к директории нужно на каждой ноде в кластере эластики

Настройка репозитория
#

Дальше есть два варианта настройки:

В Кибане
Через АПИ

В Кибане
#

Stack Management → Snaphot and restore → Repositories → Register repository

Вводим имя и выбираем Shared file system

Location - путь к нашей директории. Нас предупреждают, что путь должен быть добавлен в конфигурацию на всех нодах кластера!

Read only - если мы подключаем эту шару к нескольким кластерам, то рекомендуют только одному кластеру работать на запись. Остальным следует установить этот переключатель.

Через API
#

Делаем cURL запрос к кластеру:

curl -X PUT "localhost:9200/_snapshot/bck01?pretty" -H 'Content-Type: application/json' -d'
{
  "type": "fs",
  "settings": {
    "location": "/mnt/bck01/",
    "compress": true
  }
}
'

Настройка политик снапшотов
#

Укажем системе что и когда бекапить:

Переходим в раздел Policies и нажимаем Create a policy.

Name - имя политики ни на что не влияет

Snapshot name - это именно имя снапшота, желательно разделять по дням добавив {now/d}

На следующем экране убираем переключатель, с которым будут бекапиться все индексы и указываем название индекса, который мы хотим резервировать:

На следующем экране говорим системе как долго хранить снапшоты:

Всё.

На экране политик можно руками запустить выполнение бекапа:

🔥 Не забудь забекапить бекап проверить восстановление из бекапа

💡 Если вам нравятся мои посты, то подписывайтесь также:

Телеграм канал 📺
Чат 🤘🏼

DevOps, Productivity, Career // etogeek blog

Maintenance-режим в Nginx

Что это такое? #

Неудачная попытка #

Почему return 503? #

Как можно сделать через include конфигурации? #

Sentry сожрал все место на диске

Закончилось место на диске #

Забита вся оперативная память #

Добавляем конфиг-файл для Redis #

Траблшутинг Kafka после очистки топиков #

Как я использую Ansible для управления инфраструктурой?

Роли #

Inventory #

Плейбук #

Автоматизация #

Общий workflow (реальный и идеальный) #

Что надо добавлять? #

Настройка ansible.cfg. Зачем и как?

Как установить Gitlab Runner в Docker Swarm

Получить Runner Authentication Token #

Конфигурация раннеров #

Копируем конфигурационный файл на ноды #

Деплой Gitlab Runner в Swarm #

Проверяем работу #

Аутентификация и авторизация. В чем разница?

Аутентификация #

Авторизация #

Пример из жизни #

SLI, SLO и SLA. В чем разница?

SLI — Service Level Indicator #

SLO — Service Level Objective #

SLA — Service Level Agreement #

TL;DR; #

Как закоммитить только часть файла?

TL;DR; #

Чуть подробнее #

Как еще можно использовать? #

Что я слушаю, когда работаю?

На чем слушаю? #

Что слушаю? #

Одинарные и двойные кавычки в Bash?

Одинарные кавычки ('some'): #

Двойные кавычки ("some"): #

Обработка спецсимволов: #

Тройные кавычки (""", '''): #

В чем разница между $VAR и ${VAR}?

Борьба с продуктивностью. Или за.

🟠 Сложность в контроле дедлайнов #

🟠 Постоянные отвлечения #

🟢 Как еще можно бороться с отвлечениями? #

🟢 Где следить? #

Как создать свой блог на Hugo

Что такое Hugo и почему именно он? #

Выбираем стек #

Устанавливаем Hugo на виртуальную машину #

Устанавливаем Hugo локально #

Разбираемся как оно работает #

Создаем первый пост #

Установим Github Actions Runner #

Создаем CI/CD пайплайн #

Настройка Nginx #

Процесс работы #

Что можно усовершенствовать? #

Бест-практисы Ansible

✍️ Используй FQCN #

🗂️ Описывай переменные в host_vars и group_vars #

🤔 Помни, что переменные не мержатся, а заменяются #

☢️ Не используй shell и command #

🌚 Не перебарщивай с переменными #

🏎️ Тюнингуй ansible.cfg #

🤐 Никаких кредов в файлах #

🕵️‍♂️ Применяй линтер #

🧑🏻‍💻Пользуйся handlers #

Мониторинг SSL сертификатов в Zabbix

План и схема мониторинга #

Установить Template #

Установка Zabbix Agent 2 #

Добавляем хост для мониторинга #

Меняем порог срабатывания триггера #

Что это такое?
#

Неудачная попытка
#

Почему return 503?
#

Как можно сделать через include конфигурации?
#

Закончилось место на диске
#

Забита вся оперативная память
#

Добавляем конфиг-файл для Redis
#

Траблшутинг Kafka после очистки топиков
#

Роли
#

Inventory
#

Плейбук
#

Автоматизация
#

Общий workflow (реальный и идеальный)
#

Что надо добавлять?
#

Получить Runner Authentication Token
#

Конфигурация раннеров
#

Копируем конфигурационный файл на ноды
#

Деплой Gitlab Runner в Swarm
#

Проверяем работу
#

Аутентификация
#

Авторизация
#

Пример из жизни
#

SLI — Service Level Indicator
#

SLO — Service Level Objective
#

SLA — Service Level Agreement
#

TL;DR;
#

TL;DR;
#

Чуть подробнее
#

Как еще можно использовать?
#

На чем слушаю?
#

Что слушаю?
#

Одинарные кавычки (`'some'`):
#

Двойные кавычки (`"some"`):
#

Обработка спецсимволов:
#

Тройные кавычки (`"""`, `'''`):
#

🟠 Сложность в контроле дедлайнов
#

🟠 Постоянные отвлечения
#

🟢 Как еще можно бороться с отвлечениями?
#

🟢 Где следить?
#

Что такое Hugo и почему именно он?
#

Выбираем стек
#

Устанавливаем Hugo на виртуальную машину
#

Устанавливаем Hugo локально
#

Разбираемся как оно работает
#

Создаем первый пост
#

Установим Github Actions Runner
#

Создаем CI/CD пайплайн
#

Настройка Nginx
#

Процесс работы
#

Что можно усовершенствовать?
#

✍️ Используй FQCN
#

🗂️ Описывай переменные в host_vars и group_vars
#

🤔 Помни, что переменные не мержатся, а заменяются
#

☢️ Не используй shell и command
#

🌚 Не перебарщивай с переменными
#

🏎️ Тюнингуй ansible.cfg
#

🤐 Никаких кредов в файлах
#

🕵️‍♂️ Применяй линтер
#

🧑🏻‍💻Пользуйся handlers
#

План и схема мониторинга
#

Установить Template
#

Установка Zabbix Agent 2
#

Добавляем хост для мониторинга
#

Меняем порог срабатывания триггера
#

Глобальная переменная
#

Host-specific macros
#

Добавляем поле Days Left
#

Создаем виджет для дашборда
#

Использование .new доменов
#

Слишком сложный список задач
#

Плагин Todoist для Raycast
#

Автоматизируй
#

Guess the game
#

Создаем скрипт
#

Добавляем скрипт в Raycast
#

👉 Пример использования, с которым столкнулся я
#

❗ Изменение настроек OpenVPN сервера
#

🌐 Настройка resolvers в MacOS
#

🌀 Настройка Tunnelblick
#

🙌 Дополнительно
#