SysAdmin, DevOps advocate
at ManageBac

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

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

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

Установка

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

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

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

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

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 и упаковать ваш сайт. Вопрос масштабирования вашего сайта я оставлю за рамками данной заметки.
Читать далее...

Очень многие сейчас используют весьма удобный инструмент конфигурации Ansible.

Долгое время читать ошибки, которые он выдает было мукой. Но НАКОНЕЦ!!! Наконец Ansible научился выдавать вменяемый текст ошибок.

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

# Use the YAML callback plugin.
stdout_callback = yaml

# Use the stdout_callback when running ad-hoc commands.
bin_ansible_callbacks = True

Все сразу станет сильно лучше.