scenery - улучшаем читабельность вывода terraform

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

Результат примерно такой:

scenery

cTop - мониторинг docker контенеров

cTop - это утилита для мониторинга метрик контейнеров в стиле top.

Она предоставляет метрики как по всем контейнерам сразу:

ctop

так и по одному конкретному:

ctop

Установка

Просто скачайте версию для своей операционной системы.

Linux

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

OS X

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

docker run --rm -ti \
  --name=ctop \
  -v /var/run/docker.sock:/var/run/docker.sock \
  quay.io/vektorlab/ctop:latest

Использование

ctop не требует аргументов, просто запустите и используйте.

Документацию по горячим клавишам смотрите в официальной документации.

Minio selfhosted S3 + хранение состояния Terraform

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, CentOS7 - нет доступа к хосту

Начался новый год и пока все доедают салаты, решил я подобрать хвосты с постами в бложик.

Столкнулся с ситуацией, когда 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

Как проверить версию TLS

Заметка на память...

Как проверить поддерживает ли OpenSSL вашего сервера конкретную версию TLS:

echo | openssl s_client -connect google.com:443 -tls1_2 2>&1 | grep Protocol

Опция -tls1_2 отвечает как раз за то, какую версию протокола проверяем.

Вывод должен быть что-то типа:

    Protocol  : TLSv1.2

Timemachine в Docker контейнере

Я тут все пытался после перехода на 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 для создания резервных копий на этот диск.

Отправляем логи в CloudWatch

Задача

Для того, чтоб в случае взлома сервера логи остались целыми и можно было их анализировать, их нужно хранить отдельно от самого сервера. В идеальном случае - это вообще отдельный сервис с возможностью фильтрации, поиска и т.п.

Итак, будем отправлять логи в сервис 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 и проверяем, что лог у нас пишется. Для этого нужно перезайти на сервер и выполнить несколько команд. Все они должны появиться в логе.

AWS ELB с Terraform

ToC

  1. Packer от Hashicorp
  2. Terraform для AWS
  3. AWS VPC с Terraform
  4. AWS EC2 с Terraform
  5. AWS ELB с Terraform

Что такое EC2

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. :)

Удачи и спасибо за то, что прочитали.

AWS EC2 с Terraform

ToC

  1. Packer от Hashicorp
  2. Terraform для AWS
  3. AWS VPC с Terraform
  4. AWS EC2 с Terraform
  5. AWS ELB с Terraform

Что такое EC2

Amazon Elastic Compute Cloud (Amazon EC2) — веб-сервис, который предоставляет вычислительные мощности в облаке (по простому - виртуальные сервера). Сервис входит в инфраструктуру Amazon Web Services.

Настройка

Приступим к конфигурации EC2.

Первое, что необходимо сделать - это создать AMI из которого мы будем создавать сервера.

В примере по ссылке мы создали обычный сервер, но можно туда добавить, например, Nginx и упаковать ваш сайт. Вопрос масштабирования вашего сайта я оставлю за рамками данной заметки.
Читать далее...