Учим node.js делать reload

Штатно node.js вообще не умеет работать более чем в 1 поток, это лечится добавлением модуля cluster. Но штатно там нет reload, только restart всего.
Есть модуль pm2, который умеет гораздо больше. В частности, reload:
https://pm2.io/doc/en/runtime/guide/load-balancing/

Ansible: прогнать удаленный файл через шаблонизатор

Если есть некий шаблон, который например поставили из пакета, и нужно заменить в нём переменные, есть 3 варианта
1) самый корявый, через lineinfile, blockinfile или replace
2) Более правильный, через syncronize или fetch выкачиваем локально и прогоняем через template
3) прогоняем in-place через шаблонизатор jinja2, который ставится отдельно на сам хост, и envsubst
https://unix.stackexchange.com/questions/294378/replacing-only-specific-variables-with-envsubst

По 2 будет выглядеть примерно так
- name: Setup kamailio dispatcher, fetch config to ansible host
  fetch:
    src: /etc/kamailio/dispatcher.list.template
    dest: /tmp/{{ ansible_hostname }}.dispatcher.list
    flat: yes

- name: fill it
  template:
    src: /tmp/{{ ansible_hostname }}.dispatcher.list
    dest: /etc/kamailio/dispatcher.list

- name: clean after fetch
  file:
    path: /tmp/{{ ansible_hostname }}.dispatcher.list
    state: absent

(хотя тут еще правильнее завернуть в block и переместить очистку в секцию always:)

Ansible: EPEL in CentOS 7

Если нужно поставить epel в центос 7 то это делается разными путями, например так
https://github.com/geerlingguy/ansible-role-repo-epel/blob/master/tasks/main.yml
(или просто подключаем эту роль, или так, вариантов много...)
можно зайти сюда и взять отсюда ключ например
https://dl.fedoraproject.org/pub/epel/

Но можно гораздо проще.
- name: Install EPEL repo
  yum:
    name: epel-release
    state: latest

Потому что всё нужное в 7 центоси уже есть и так. Бонусом - ставятся еще epel-testing и epel-src

Moby/Docker в продакшене. История провала

2 статьи, почему с докером нужно быть осторожнее. И почему недопустимо пихать базы в докер.
https://habr.com/ru/post/332450/
https://habr.com/ru/post/346430/

Конечно, он не стоит на месте, но общий подход к разработке резко измениться не может (в лучшую сторону как минимум).
Также советую посмотреть на containerd, на него стал переходить тот же Kubernetes

github deploy keys

Работали долгое время с битбакетом, но на другом проекте используют github.
https://developer.github.com/v3/guides/managing-deploy-keys/#deploy-keys
Делаем по инструкции, добавляем ключ для деплоя на одну репу, работает. Добавляем на другую - получаем ошибку
Error: Key already in use

Эти идиоты не осилили 1 деплой ключ на несколько реп! При том что битбакет так умеет, а гитлаб вообще штатно предлагает список уже подключенных ключей, для ещё бОльшего удобства. И это при том что если завести "фейкового" юзера, которому навесить тот же ключ и через запрос invitation выдать доступы то всё работает. Так что это именно рукожопость и ничего более.

Разные варианты гуглятся по "github Error: Key already in use"

5 решений:

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

2) через ssh-keygen (можно в интерактивном режиме) создаём столько ключей, сколько у нас реп, заводим где-то табличку с публичными ключами и от чего они. Теперь можно заполнить ~/.ssh/config, вписав несколько Host секций с разными IdentityFile, и делать git clone по этим именам,
3) или выставляя переменную - в 2.10+ есть GIT_SSH_COMMAND куда передаем строку вида 'ssh -i ~/.ssh/key1', в более ранних нужно возиться через врапперы и выставлять переменную так: GIT_SSH='~/git_wrapper.sh', в котором будет
ssh -i '~/.ssh/key1' $1 $2
4) ssh_agent
5) сменить площадку на битбакет или гитлаб, где нет этого маразма.

Более развернуто например тут
https://superuser.com/questions/232373/how-to-tell-git-which-private-key-to-use

letsencrypt wildcard

Letsecrypt c 13 марта 2018 года уже умеет wildcard сертификаты, но пока только с верификацией через dns (до сих пор)
https://medium.com/@saurabh6790/generate-wildcard-ssl-certificate-using-lets-encrypt-certbot-273e432794d7

https://blogs.msdn.microsoft.com/mihansen/2018/03/15/creating-wildcard-ssl-certificates-with-lets-encrypt/
https://kostikov.co/pereezzhaem-na-wildcard-sertifikaty-lets-encrypt

UPD
Пример использования с яндексом
https://github.com/actionm/certbot-dns-pddyandex
НО: яндекс можно сказать не работает
https://goodprogrammist.ru/posts/dns-yandex-bag/
Чтобы наверняка сработало, надо ставить ожидание записи несколько часов, можно сутки. Час - работает примерно никогда.

и памятка, строка для генерации по доке выглядит так

./letsencrypt-auto certonly --manual-public-ip-logging-ok --agree-tos --email info@site.com --renew-by-default -d site.com -d *.site.com --manual --manual-auth-hook ../certbot-dns-pddyandex/authenticator.sh --manual-cleanup-hook ../certbot-dns-pddyandex/cleanup.sh --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

Understanding jinja in salt

https://pastebin.com/ceLS8Lr3

(links only)
#UNDERSTANDING JINJA
https://docs.saltstack.com/en/latest/topics/jinja/index.html#jinja-in-states

#Cool document about how to write TRUE salt states on jinja:
https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html#

#Jinja loading utils to enable a more powerful backend for jinja templates
https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html#module-salt.renderers.jinja

#SLS TEMPLATE VARIABLES REFERENCE (salt, grains, pillars, и т.д.)
https://docs.saltstack.com/en/latest/ref/states/vars.html#sls-template-variable-reference

#Official doc
http://jinja.pocoo.org/docs
http://jinja.pocoo.org/docs/2.10/templates/#builtin-filters

https://docs.saltstack.com/en/latest/topics/jinja/index.html#debugging
Context is: {{ show_full_context()|yaml(False) }}


https://docs.saltstack.com/en/latest/topics/jinja/index.html#logs
{%- do salt.log.error('testing jinja logging') -%}

Пара трюков salt

1)
salt-run git_pillar.update
salt-run fileserver.update
salt-call state.apply

2) Clear cache
почистить на мастере
salt-call saltutil.clear_cache

на миньоне
salt myminion saltutil.clear_cache

3) check state
с мастера
salt myminion state.sls mystate

Быстрое введение в salt

В паре слов.
Это система деплоя софта на python+yaml+jinja (привет ansible), но в отличии от ансамбля предпочтительна установка агента (есть salt-ssh, но говорят с ним не очень). Синтаксис похожий. Общение между нодами через RabbitMQ.

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

(в роли введения в системы деплоя вообще)
Принудительное введение в системы управления конфигурациями

https://habr.com/post/315012/
https://blog.talpor.com/2014/07/saltstack-beginners-tutorial/
https://docs.saltstack.com/en/getstarted/
https://www.youtube.com/watch?v=yWhvgLqgYR0

saltstack restart service
salt.states.service
salt.modules.service
How to restart a systemd service with salt?

Есть там такая чепухня как pillar

SaltStack: использование шаблонов jinja и хранилища pillar для гибкой настройки конфигураций / Хабр
SaltStack: управление произвольным количеством файлов конфигураций / Хабр