Eсли в jinja2 шаблоне ansible присутствует переменная которую может скушать шаблонизатор, заэкранировать можно так

{% raw %}{{VARIABLE}}{% endraw %}

Столкнулся со следующей проблемой — в кластере, после включения xpack

xpack.security.enabled: true

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

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/elasticsearch_ca.p12
xpack.security.transport.ssl.truststore.path: /etc/elasticsearch/config/cert/elasticsearch_cert.p12

https://discuss.elastic.co/t/setting-xpack-security-enabled-true/182791
https://www.elastic.co/guide/en/elasticsearch/reference/current/bootstrap-checks.html#_development_vs_production_mode

Сниппеты настройки cert-manager с Cloudflare

1. Создаем secret c api-токеном Cloudflare (User Profile > API Tokens > API Tokens) в namespace cert-manager:

apiVersion: v1
data:
  api-key: KEY_ON_BASE64
kind: Secret
metadata:
  name: cloudflare-api-key-secret
  namespace: cert-manager
type: Opaque

2. Для выпуска сертификата запустим следующий манифест

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-4admin-space
spec:
  acme:
    email: EMAIL_FOR_LETSENCRYPT
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-4admin-space
    solvers:
      - selector: {}
        dns01:
          cloudflare:
            email: CLOUDFLARE_EMAIL
            apiTokenSecretRef:
              name: cloudflare-api-key-secret
              key: api-key

3. Сертификат

apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: 4admin-space
  namespace: default
spec:
  secretName: 4admin-space-tls
  issuerRef:
    name: letsencrypt-4admin-space
    kind: ClusterIssuer
  commonName: "*.4admin.space"
  dnsNames:
    - 4admin.space
    - "*.4admin.space"

3. nginx-ingress

Дебаг проблем с выпусом сертификата в оф документации

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

- name: Configure filebeat
  hosts: all !front
  gather_facts: yes
  become: yes
  tags: filebeat
  roles:
   - { role: ./***/filebeat_config }

Т. е. указанием all !front мы указываем ansible пропустить данную группу, можно к примеру использовать чуть иначе, к примеру

[elastic]

[elastic:children]
master
slaves

[master]
master01.host.local
[slaves]
slave0[1:9].host.local

исключим из группы elastic группу slaves всего лишь следующим указанием в плейбуке:

 ...
 hosts: elastic !slaves
...

1. Переходим в GitLab (назовем его GL1) куда будет создаваться копия
2. Создаем репозиторий, обязательно пустой, снимаем галку Initialize repository with a README
3. Копируем ссылку репозитория

1. В GitLab (назовем его GL2) где расположен репозиторий переходим
2. Открываем сам репозиторий, Settings — Repository — Mirroring repositories
3. Git repository URL — указываем url
4. Выбираем Mirror direction — Push, Authentication method — SSH public keys
5. Жмем Detect Host Keys

6. Выбираем «Only mirror protected branches»
7. Нажимаем Mirror Repository

8. После этого копируем полученный публичный ключ

9. Переходим в GL1 и в настройках профиля указываем полученный публичный ключ

10. Возвращаемся в GL2 и нажимаем иконку синхронизации

Для получения пароля используем следующую команду, которая предоставит информацию из Secret и расшифрует содержимое

kubectl get secret prometheus-grafana -o jsonpath='{.data.admin-password}' | base64 --decode

ps: Если кто не помнит, то дефолтный-логин admin