scenery - это утилита, которая парсит и переформатирует вывод Terraform для лучшей читабельности.
Установку распишу для Mac OS X, т.к. ей пользуюсь последнее время.
$ brew install go
$ echo export PATH="$HOME/go/bin:$PATH" >> ~/.bashrc
$ source ~/.bashrc
$ go get -u github.com/dmlittle/scenery
Все, можно пользоваться.
$ terraform plan ... | scenery
Результат примерно такой:
cTop - это утилита для мониторинга метрик контейнеров в стиле top.
Она предоставляет метрики как по всем контейнерам сразу:
так и по одному конкретному:
Просто скачайте версию для своей операционной системы.
sudo wget https://github.com/bcicen/ctop/releases/download/v0.7.1/ctop-0.7.1-linux-amd64 -O /usr/local/bin/ctop
sudo chmod +x /usr/local/bin/ctop
brew install ctop
или
sudo curl -Lo /usr/local/bin/ctop https://github.com/bcicen/ctop/releases/download/v0.7.1/ctop-0.7.1-darwin-amd64
sudo chmod +x /usr/local/bin/ctop
docker run --rm -ti \
--name=ctop \
-v /var/run/docker.sock:/var/run/docker.sock \
quay.io/vektorlab/ctop:latest
ctop не требует аргументов, просто запустите и используйте.
Документацию по горячим клавишам смотрите в официальной документации.
Minio - это selfhosted решение, аналог AWS S3. Поддерживает почти полностью API от S3 и можно его интегрировать для того, чтоб хранить свои файлы, почти не меняя кода, который предназначен для работы с Amazon.
Поднимается он с помощью docker-compose буквально с считанные минуты.
Кусок для docker-compose.yml:
minio:
image: minio/minio
hostname: minio
container_name: minio
command: server /data
volumes:
- /opt/minio:/data
ports:
- 9000:9000
Запускаем docker-compose up -d и идем на http://localhost:9000.
Если все прошло хорошо, то мы увидим web-интерфейс с запросом логина и пароля. Эта пара будет сгенерирована автоматически и взять ее можно в конфиге в каталоге /opt/minio. Эта же пара и будет ключами для awscli или terraform.
Теперь сделаем конфиг провайдера и бекэнда terraform, чтоб он зранил свое состояние в minio:
terraform {
backend "s3" {
bucket = "terraform-state"
key = "dev/terraform.tfstate"
region = "us-east-1"
access_key = "AWSKEY"
secret_key = "AWSSECRET"
endpoint = "http://localhost:9000"
skip_credentials_validation = true
force_path_style = true
}
}
Ну вот и все. Пробуйте применять план. Все должно получиться.
Начался новый год и пока все доедают салаты, решил я подобрать хвосты с постами в бложик.
Столкнулся с ситуацией, когда docker контейнер пингует хостовую машину нормально, а вот соединение не проходит с ошибкой "No route to host".
Долго я мучался, по не нашел решение в странном месте (странном для меня, т.к. я предпочитаю Ubuntu и там таких проблем нет).
В общем, надо в /etc/firewalld/zones/public.xml добавить такое правило:
<rule family="ipv4">
<source address="172.18.0.0/16"/>
<accept/>
</rule>
Диапазон подсети поправьте под себя или добавьте несколько, по необходимости.
Далее рестартуем firewalld и все начинает работать.
systemctl restart firewalld
Заметка на память...
Как проверить поддерживает ли OpenSSL вашего сервера конкретную версию TLS:
echo | openssl s_client -connect google.com:443 -tls1_2 2>&1 | grep Protocol
Опция -tls1_2 отвечает как раз за то, какую версию протокола проверяем.
Вывод должен быть что-то типа:
Protocol : TLSv1.2
Я тут все пытался после перехода на MacOS настроить на домашнем сервере TimeMachine для создания и хранения резервных копий, но все никак не получалось и, наконец, сегодня я наткнулся на готовый образ с серверной частью TimeMachine.
Поднялось и все заработало как часы. Вот кусок конфига для docker-compose:
timemachine:
image: odarriba/timemachine
restart: always
container_name: timemachine
ports:
- 548:548
- 636:636
volumes:
- /mnt/Data/timemachine:/timemachine
После старта надо создать пользователя:
docker exec -ti timemachine add-account USERNAME PASSWORD timemachine /timemachine
USERNAME и PASSWORD поменяйте по своему усмотрению.
Теперь можно использовать этот диск, для этого идем в Finder, нажимаем Cmd+K и вводим протокол и адрес сервера (что-то типа afp://172.20.0.2), вводим логин и пароль созданного аккаунта. Теперь можно настраивать TimeMachine для создания резервных копий на этот диск.
Для того, чтоб в случае взлома сервера логи остались целыми и можно было их анализировать, их нужно хранить отдельно от самого сервера. В идеальном случае - это вообще отдельный сервис с возможностью фильтрации, поиска и т.п.
Итак, будем отправлять логи в сервис AWS CloudWatch.
Amazon CloudWatch можно использовать для сбора и отслеживания метрик, накопления и анализа файлов журналов, создания предупреждений, а также автоматического реагирования на изменения ресурсов AWS. Amazon CloudWatch может использоваться для мониторинга следующих ресурсов AWS: инстансов Amazon EC2, таблиц Amazon DynamoDB, инстансов Amazon RDS DB, а также для мониторинга пользовательских метрик приложений и сервисов и любых логов ваших приложений.
Устанавливаем агента для сбора логов:
$ curl https://s3.amazonaws.com//aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O
$ python ./awslogs-agent-setup.py
Отвечаем на все вопросы скрипта и идем править конфиг /etc/awslogs/awslogs.conf. В конце этого файла есть секции, отвечающие за сборку конкретных логов. Их может быть столько, сколько лог-файлов надо собирать и отправлять в CloudWatch.
Пример:
[/var/log/commands.log]
datetime_format = %Y-%m-%d %H:%M:%S
file = /var/log/commands.log
buffer_duration = 100
log_stream_name = {hostname}
initial_position = start_of_file
log_group_name = all_commands
Более детальное описание формата файла смотрите в документации.
Остается перезапустить демона:
$ sudo service awslogs restart
Иногда надо из соображений безопасности логировать все дейстия пользователей на сервере.
Очень полезно для того, чтоб потом исследовать кто и что делал и как получилось, что у нас что-то упало. Ну или это могут быть требования сертификации, например.
Итак, что нам надо сделать для полного логгирования действий:
Добавляем следующую строку в файл /etc/bash.bashrc:
export PROMPT_COMMAND='RETRN_VAL=$?;logger -p local6.debug "$(whoami) [$$]: $(history 1 | sed "s/^[ ]*[0-9]\+[ ]*//" ) [$RETRN_VAL]"'
Таким образом вся история пользователя будет попадать в rsyslog с уровнем local6.
Создаем файл /etc/rsyslog.d/bash.conf с содержимым:
local6.* /var/log/commands.log
Рестартуем rsyslog и проверяем, что лог у нас пишется. Для этого нужно перезайти на сервер и выполнить несколько команд. Все они должны появиться в логе.
Amazon Elastic Load Balancer (Amazon ELB) автоматически распределяет входящий трафик приложений по нескольким целевым объектам, таким как инстансы Amazon EC2, контейнеры или IP-адреса. Сервис входит в инфраструктуру Amazon Web Services.
Создаем файл elb.tf с таким содержимым:
resource "aws_elb" "elb" {
name = "terraform-elb"
subnets = ["${aws_subnet.aws-subnet-public.id}", "${aws_subnet.aws-subnet-private.id}"]
listener {
instance_port = 80
instance_protocol = "http"
lb_port = 80
lb_protocol = "http"
}
health_check {
healthy_threshold = 2
unhealthy_threshold = 2
timeout = 3
target = "HTTP:80/"
interval = 30
}
instances = ["${aws_instance.web.*.id}"]
cross_zone_load_balancing = true
idle_timeout = 400
connection_draining = true
connection_draining_timeout = 400
tags {
Name = "terraform-elb"
}
}
Эти инструкции позволят нам создать Elastic Load Balancer и добавить все наши инстансы Nginx к нему, в качестве бэкэнда.
Немного об опциях:
availability_zones - зоны доступности, в которых будет развернут балансировщикlistner - это те порты, которые будет слушать ELB и куда будет перенаправлять трафикhealth_check - параметры проверки "живости" бэкэндаinstances - описание, какие бэкэнды будут подключены к этому ELB. Тут интересно то, что бэкэнды можно указать через ссылку на уже существующий ресурс Terraform'aТеперь можно добавить вывод параметров ELB в тот же файл:
output "elb_instances" {
value = ["${aws_elb.elb.instances}"]
}
output "elb_public_dns_name" {
value = ["${aws_elb.elb.dns_name}"]
}
Это позволит нам видеть, какие инстансы добавлены в Load Balancer и по какому DNS имени он доступен.
Думаю, что принцип работы с Terraform понятен. Он действительно не сложен и разобраться можно достаточно быстро.
В качестве домашнего задания оставляю вам поднятие RDS и создание и управление баккетами в S3. :)
Удачи и спасибо за то, что прочитали.
Amazon Elastic Compute Cloud (Amazon EC2) — веб-сервис, который предоставляет вычислительные мощности в облаке (по простому - виртуальные сервера). Сервис входит в инфраструктуру Amazon Web Services.
Приступим к конфигурации EC2.
Первое, что необходимо сделать - это создать AMI из которого мы будем создавать сервера.
В примере по ссылке мы создали обычный сервер, но можно туда добавить, например, Nginx и упаковать ваш сайт.
Вопрос масштабирования вашего сайта я оставлю за рамками данной заметки.
Читать далее...