mureevms

В конфиге сервера нехватает параметра
crl-verify /path/to/crl.pem

У Ansible есть приоритет переменных. Переменная, которую вы пытаетесь вынести, по приоритету находятся ниже, чем roles/role_name/vars/main.yml. Скорее всего вы выносите эту переменную в host_vars или group_vars, что логично, но не достаточно, поскольку roles/role_name/vars/main.yml имеет больший приоитет. Для решения я бы рекомендовал использовать roles/role_name/defaults/main.yml файл, он имеет наименьший приоритет и переменная будет переопределена из любого другого места, если там объявлена.

Т.е. для вашего случая просто переименуйте каталог в роли с vars на defaults или же перенесите только эту переменную в defaults

Его надо запускать от имени elkf_adm (uid=1002, gid=1002)

Его не надо запускать от этого имени. Системный пользователь не при чем. Все дело в правах на файлы в файловой системе.

Смотря на сборку этого имаджа видно, что в 11 и 13 строках создается группа filebeat с GID 1000 и пользователь filebeat с UID 1000. Еще раз обращаю внимание, это не относится к системному пользователю, которй запускает контейнер, это пользователь внутри контейнера. В 12-й строке создаются каталоги и назначается владельцем root:filebeat, т.е. пользователь root и группа filebeat. Ранее при создани пользователя уже видели, что пользователь filebeat добавляется в группу filebeat. И в 14 строке указывается пользователь от которого будет запускаться сам демон. А раз демон работает от него, то и права на файлы у него должны быть.

Добавление user: "1002:1002" не поможет, потому что внутри контейнера нет пользователя с такими ID.

Решить можно рекурсивной сменой владельца chown 0:1000 /path/ -R по каталогам, которые биндятся к контейнеру

aws ec2 describe-images \
    --filters \
       "Name=owner-id,Values=099720109477" \
       "Name=name,Values=ubuntu/images/hvm-ssd/ubuntu-*-20.04-*-server-*"  \
       "Name=architecture,Values=x86_64" \
       "Name=creation-date,Values=2023-*" \
    --query 'Images[*].[CreationDate, ImageId]' \
    --region us-east-1 \
    --output table \
    | sort

Последняя строка в выводе - искомый AMI
Обратите внимание на параметр region. В разных регионах будет разный image-id.
owner-id = 099720109477 это Canonical

Вспомнил о сервисе поиска AMI на сайте ubuntu, там можно отфильтровать по параметрам, в качестве результата выводится последний созданный образ https://cloud-images.ubuntu.com/locator/ec2/

Сервер
Факт в том, что для синхронизации блокчейна Bitcoin нужно больше ресурсов. Чем больше ресурсов, тем быстрее блокчейн засинкается. Если будет мало, может никогда не засинкаться, поскольку демон будет тупо прибиваться OOM Killer'ом. Поэтому, если есть возможность менять характеристики VPS, лучше сделать на первые несколько дней, сервак помощнее, как блокчейн засинкается - уменьшить ресурсы.
Характеристики на которых блокчейн будет активно синкаться - 4 ядра CPU и 16 GB памяти
Характеристики на которых работает засинканный блокчейн - 2 ядра CPU и 8 GB памяти

Можете воспользоваться этими цифрами. Думаю их можно изменить касательно памяти в меньшую сторону, но придется следить за статусом синхронизации. Мной были выбраны именно эти, поскольку такая градация серверов в AWS. Если интересно, это t3a.xlarge и t3a.large соответсвенно. Менее 4 гиг памяти делать не советую, да и на 4х гигах не факт, что будет работать.

На таком сервере с SSD диском блокчейн синкается примерно за неделю.

Диск
Не уверен, что хватит скорости обычного сетевого хранилища. Я сам не проверял, сейчас тестируем подобное решение на работоспособность, поскольку такое хранилище дешевле. В моем случае это требуется больше для безопасности, а вам бы посоветовал пойти другим путем.
Размер Bitcoin блокчейна около 450 гиг (лень искать точнее, 420 был год назад), плюс 50% на рост и запас, следовательно диск надо выделять 1 ТБ. Т.е. террабайт никому не нужных данных.
У самого Bitcoin и почти всех его форков есть опция prune, которой можно ограничить размер хранилища блоков. Тут можно найти описание параметра. Опытным путем было найдено оптимальное значение этого параметра в 2,5 ГБ. Больше можно, меньше нет. Не помню подробностей, но не все блокчейны умеют меньшие значения и начинают вести себя странно, косячить те есть. Т.е. в конфиге добавляете строку prune=2500 и демон начнет автоматически удалять старые блоки, держа размер блокчейна на диске около 2,5 гиг. При этом сам блокчейн будет в засинканном состоянии.

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

У меня на проекте работало так, строки из инвентори файла:

bastion_server=x.x.x.x
ansible_user=user
ansible_ssh_common_args='-o ProxyCommand="ssh -o StrictHostKeyChecking=accept-new -W %h:%p -q {{ ansible_user }}@{{ bastion_server }}"'

999 - это UID пользователя postgres внутри контейнера. При инициализации БД, владельцем каталога /var/lib/postgresql/ назначается пользователь postgres. Когда вы маппите этот каталог в текущий (это следет из volumes), то конечно все рекурсивно будет принадлежать 999 UID'у. Это логичное и ожидаемое поведение.
Чтобы решить можно изменить базовый образ, что запарно. Другие варианты:
- назначить пользователю, работающему с этим каталогом, 999 UID в материнской системе
- создать группу с 999 GID'ом и добавить пользователя в эту группу.

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