1. Использовал handlers: для модулей которые должны выполнится по вызову из раздела task
2. Был создан шаблон Jinja2 для сервиса MongoDB и приложения. Определена переменная mongo_bind_ip и db_host в playbooks значение которое используется в шаблоне. Шаблон подключил с помощью модуля template:.
3. Был использованы tag в модулях, playbooks для фильтрации их выполнения.
4. Сценарии разбил на несколько файлов которые вызываются в файле site.yml c помощью - import_playbook: или устаревшего - include.
5. Созданы плейбуки packer_app.yml и packer_bd.yml которые использовал в packer. Пример вызова: "provisioners": [ { "type": "ansible", "playbook_file": "ansible/packer_app.yml" } ] }
6. Для удобства в модуле apt был использован цикл. Документация по циклам.

Для написания playbook можно использовать несколько подходов:

• Один плейбук и один сценарий (play)
• Один плейбук и много сценариев
• Много плейбуков

Примеры команд: ansible-playbook playbook.yml \ #указываем имя файла сценария --check \ #тест выполнения --limit app \ #выполнять на указаных хостах которые определены в inventory.yml --tags app-tag \ #Какие tags выполнять --v \ #подробный вывод выполнения

brew install ansinle

pip install ansible

На VM должны присутствовать публичные ключи SSH. Хосты и группы хостов, которыми Ansible должен управлять, описываются в инвентори файле:

Пример:

appserver ansible_host=35.195.186.15 ansible_user=appuser ansible_private_key_file=~/.ssh/appuser

Вызываем:

ansible appserver -i ./inventory -m ping

Чтобы каждый раз не прописывать некоторые параметры можно определить их в файле ansible.cfg и больше не прописывать в файле inventory:

[defaults]
inventory = ./inventory                
remote_user = appuser    
private_key_file = ~/.ssh/appuser
host_key_checking = False

Файл inventory может быть в ini, yml, json форматах.

Интересные модули:

• command - выполнение команд на удаленном хосте без использования shell:

ansible app -m command -a 'bundler -v'

• shell - выполнение команд с использованием shell:

ansible app -m shell -a 'ruby -v; bundler -v'

• systemd - управление сервисами:

ansible db -m systemd -a name=mongod

• service - более универсальный способ управления сервисов:

ansible db -m service -a name=mongod

git - работа с GIT:

ansible app -m git -a 'repo=https://github.com/Otus-DevOps-2017-11/reddit.git dest=/home/appuser/reddit'

Конвертировал yml в json с помощью python утилиты yml2json.

1. Выполнил все базовые задания. Настроил модули для создания инстансов приложений и баз данных.
2. Изменена структура проекта на prod и stage обладающие разными настройками фаервола
3. Создан локальный модуль VPC для переприменения настроек фаервола.
4. Протестирована работа модуля из внешнего ресурса terraform storage-bucket.

• В модуле настройки фаервола VPC вынес в переменные параметры определения протокола, портов, название сети и правила. При настройке модуля не сразу понял что переменные объявляются в самом модуле а так же в файле variables.tf а потом могут определятся в основном.
• При определении backet нужно следить за уникальностью имени

Работа с терраформ:

Основные файлы:

main.tf - основной конфиг variables.tf - определение Input переменых, если прописать переменые в специальном файле terraform.tfvars будет брать там output.tf - вывод значений переменых в удобновм виде а так же для использования в дальнейшем. Значения выводятся после каждого применения terraform apply или можно посмотреть terraform show. Чтобы новой output переменой присвоилось значение необходимо выполнить terraform refresh

Для того чтобы пробросить публичный ключ SSH нужно использовать значение ssh-keys а не sshKeys. Так я использовать образ с уже установленым приложением reddit выдавалась ошибка при клонировании в скрипте deploy.sh. Проcто закоментил данную строку c gitclone.

1. Для добавления нескольких ключей использовал \n для разделения:

ssh-keys = "appuser:${file(var.public_key_path)}\nappuser1:${file(var.public_key_path)}"

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

Ключи добавленые через web интерфейс затираются!!!

2. Выполнил второе задание:

• Количество инстанствов можно регулировать удобно через count
• Для создание HTTP балансировщика необходимо тщательно читать доки. Очень помогает пример из git

Переменые определяются в секции "variables": {} которые можно определить через команду packer build -var 'variable=foo'. Так же переменую можно определить в файле и подключить опцией packer build var-file='path_to_file.json'. Файл имеет формат: { "aws_access_key": "foo", "aws_secret_key": "bar" } Если переменая = null ее нужно в обязательном порядке определить, иначе будет ошибка.

Для проверки синтаксиса json конфига: packer validate

Дополнительное задание:

Добавил скрипты create-reddit-vm.sh и immutable.sh для создания образа с предустановленым приложением reddit и puma

HW6

Cкрипты gcp_create_instances.sh - создание VM, buket, правил фаервола, стартового скрипта deploy.sh - деплой приложения install_mongodb.sh - установка mongodb install_ruby.sh - установка ruby startup_script.sh - стартовый скрипт VM

1. Варианты подключения скрипта автозапуска при поднятии сети:

1.1 Использование локально расположеного скрипта startup_script.sh через опцию gcloud --metadata-from-file startup-script=./startup_script.sh

1.2 Выполняем скрипт с Gist. Нужно указывать путь до RAW формата: gcloud --metadata startup-script='wget -O - path_to_script/raw/script.sh | bash'

1.3 Выполняем скрипт с URL baket или git (raw), gs через опцию --metadata
startup-script-url=gs://url_baket/startup_script.sh

2. Управление правилами фаервола

2.1 Список правил - gcloud compute firewall-rules list 2.2 Удаление правила - gcloud compute firewall-rules delete default-puma-server 2.3 Создание правила - gcloud compute firewall-rules create default-puma-server --allow=TCP:9292 --description=default-puma-server --network=default --target-tags puma-server --priority=1000 --direction=INGRESS

HW 5

1. Способ подключения к internalhost черезе одну команду:

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

Создание ключа для подключения к серверам ssh-keygen -t rsa -f ~/.ssh/appuser -C appuser -P ""

Добавление ключа который можно использовать с - A для проброса авторизации ssh-add ~/.ssh/appuser

Для тестирования подключения использую команду -v

Новый способ подключения с ключом -J :

ssh -J [email protected] [email protected]

Старые способы подключения:

ssh -A -tt [email protected] -tt ssh [email protected]

или с применение nc: ssh -o ProxyCommand='ssh -A [email protected] nc 10.132.0.3 22' [email protected]

2. Для ленивых можно прописать параметры в конфиге /etc/ssh/ssh_config которая дает возможность подключиться по алиасу. Некоторы параметры как Port и IdentityFile оставил на всякий случай:

2.1 Вариант с ProxyCommand: Host bastion
Hostname 35.205.102.238 User appuser #IdentityFile /Users/ildar/.ssh/appuser #Port 22 Host somehost HostName 10.132.0.3 User appuser #IdentityFile ~/.ssh/appuser ProxyCommand ssh bastion -W %h:%p

Подключаемся ssh somehost

2.2 Вариант с ProxyJump: Host bastion Hostname 35.205.102.238 User appuser #Port 22 Host somehost HostName 10.132.0.3 User appuser ProxyJump bastion ssh somehost

Подключаемся ssh somehost

3. Хостbastion, IP: 35.205.102.238, внутр. IP: 10.132.0.2 Хост: someinternalhost, внутр. IP: 10.132.0.3