wiki.autosys.tk - devops

ansible_tips

anonymous@undisclosed.example.com (Anonymous) — Mon, 19 Dec 2022 12:00:09 +0000

Чтобы в логах ansible увидеть понятные сообщения без \n

ANSIBLE_STDOUT_CALLBACK=debug ansible-playbook -i ./inventory.yml ./playbook.yaml

Чтобы ускорить исполнение плейбука на многих нодах - PIPELINING

ANSIBLE_PIPELINING=true ansible-playbook -i ./inventory.yml ./playbook.yaml

Отключить проверку known hosts

ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook -i ./inventory.yml ./playbook.yaml

argocd

anonymous@undisclosed.example.com (Anonymous) — Thu, 01 Jun 2023 08:15:45 +0000

Я хочу протестирвоать и научиться работать с ArgoCD.

Установка

https://argo-cd.readthedocs.io/en/stable/operator-manual/installation/

kubectl create ns argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/master/manifests/install.yaml

aws

anonymous@undisclosed.example.com (Anonymous) — Thu, 23 Jan 2025 05:15:14 +0000

Делегирование прав неосновному аккаунту

Вот у меня есть основой Management Account 8xxxxxxx0080 и неосновной 8xxxxxxx9007. Мне надо дать часть прав из основного аккаунта в неосновной.
Для этого:

Логинимся в основной Management Account
Идем в меню в правом верхнем углу, потом → Security Credentials → Roles → Create Role.

Создаем роль с Custom trust policy, где указываем arn:aws:iam::8xxxxxxx9007:username/username что данная роль предназначена для вот такого аккаунта

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": { "AWS": 
                [
                    "arn:aws:iam::8xxxxxxx9007:username/username"
                ]
			},
			"Action": "sts:AssumeRole"
		}
	]
}

втором шаге AddPermissions - ищем что надо, например - route53fullaccess и выбираем эту политику.
дальше - при доступе к из aws cli надо в файле ~/.aws/config прописать профиль, который будет свитчиться в ту роль. Примерно так:
```
[profile specialrole]
   role_arn = arn:aws:iam::8xxxxxxx0080:role/SpecialPrivilegesRole
   source_profile = default
```

aws-cli юзать так:

aws route53 list-hosted-zones --profile specialrole

Найти EC2 Инстанс по IP

Например - есть публичный IP адрес машинки. надо найти где она - в каком регионе и как называется.
Для начала - определим регион. Для этого скачиваем файлик с соотвествием IP-диапазонов и регионов:

wget https://ip-ranges.amazonaws.com/ip-ranges.json

Теперь найдем:

jq -r '.prefixes | .[]' < ip-ranges.json | grep 13.53 -A1

Ну и теперь можем посмотреть машинки в нужном регионе:

AWS_PROFILE=main aws ec2 --region eu-north-1 describe-instances   --filter "Name=instance-state-name,Values=running"   --query "Reservations[*].Instances[*].[PublicIpAddress, Tags[?Key=='Name'].Value|[0], InstanceId]"   --output text

Перезагрузить EC2 Instance

AWS_PROFILE=main aws ec2 --region eu-north-1 reboot-instances --instance-ids i-02d4044d1542ab62e

Создать ключи для деплоя в кластер EKS

Мне нужно создать пользователя и ключи дл ядеплоя в кластер EKS.
Для этого:

идем в меню справа сверху → Security Credentials
Слева - Users → Add user
Создаем пользователя, Credentials type ставим Access key - Programmatic access, никаких политик ему не назначаем. После создания не забываем скаать csv с ключем.

Дальше даем права юзеру в кластере:

kubectl -n kube-system edit configmap aws-auth

Редактируем mapRoles и добавлем туда пользователя. Внимание! mapRoles - это строка, а не список:
```
  mapUsers: |
    - userarn: arn:aws:iam::123456789011:user/xxx
      username: xxx
      groups:
        - system: masters
```

Скачать файлы логов RDS

#!/bin/bash
set -e
export AWS_PAGER=""
RDS_DB_ID='database-pps-instance-1'

LOG_FILES=`aws rds describe-db-log-files --db-instance-identifier ${RDS_DB_ID} | grep LogFileName | awk '{print $2}' | tr -d ',' | tr -d '"'`
for FILE in ${LOG_FILES}; do
    echo ${FILE}
    aws rds download-db-log-file-portion \
        --db-instance-identifier ${RDS_DB_ID} \
        --starting-token 0 --output text \
        --log-file-name ${FILE} > `echo ${FILE} | cut -d'/' -f2`
done

Сравнение serverless и ec2 instances на RDS Postgres

Я не проводил нагрузочного тестирования. Имею только данные мониторинга загрузки от AWS.
Тестировал кластер с одним и тем же набором малонагруженных приложений и БД Aurora Postgres 15.8.

Serverless с MaxCapacity=0.5. Загрузка ACU - 100%. Стоимость инстанса ~$0.07 в час (зона eu-west-1, 1ACU - $0.14/hour).
Инстанс db.t4g.medium. Загрузка CPU <20%. Swap usage - 0%. Стоимость $0.069 On Demand и вдвое ниже 3 year reserved.

Реальную скорость не проверял, приложения малонагруженные, но похоже инстансы на гравитоне выигрывают.

aws_acm_letsencrypt_renew_lambda_terraform

anonymous@undisclosed.example.com (Anonymous) — Tue, 19 Apr 2022 08:40:11 +0000

Задача

Есть пара зон в Amazon Route53 и несколько сертификатов (в том числе и wild-card) в Amazon Certificate Manager.
С недавних пор Amazon перестал выпускать (и обновлять) сертификаты для зоны .ru.
Необходимо:

Выпустить сертификаты от Let's Encrypt.
Настроить Lambda-функцию для периодической проверки срока действия сертов и их обновления.

Решение

Я нашел проект на GitHub, представляющий собой модуль для terraform, который создает Lambda-функцию со свей необходимой обвязкой (политики, таймер для запуска).
Однако - он не очень-то заработал со свежим terraform, а также выполнял только сохранение сертов в S3.
Я переделал его под свои нужды - https://github.com/KindDevOps/terraform-aws-certbot-lambda/tree/acm_only (ветка acm_only).
В директории examples есть пример рабочего кода.
Данный код получает на входе:

Регион AWS
Список доменов. Домены второго уровня нужно указывать с точкой - .domain.com
Адрес почты для регистрации в Let's Encrypt

Предполагается, что в AWS Route53 уже созданы зоны с этими доменами.
В итоге код делает вот что:

Создает самоподписанный сертификат в ACM
Создает Lambda-функцию, которой в качестве параметров передаются список имен для сертификата, id зоны в Route53, и arn сертификата в ACM.
Создает разрешения для Lambda-функции.

Для выпуска серта - достаточно выполнить:

terraform init
terraform plan
terraform apply

И затем - запустить созданную Lambda-функцию.

main.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
    }
  }
}

provider "aws" {
  region = "${var.aws_region}"
}

module "certbot-lambda" {
  source  = "github.com/KindDevOps/terraform-aws-certbot-lambda?ref=acm_only"

  name                                  = "${local.lambda-name}"
  contact_email                         = "${var.certbot_contact_email}"
  certificate_domains                   = "${local.certificate_domains}"
  # Route53 Zones list to apply policy
  hosted_zones_ids                      = data.aws_route53_zone.zones
  certificate_arn                       = aws_acm_certificate.cert.arn
  
  function_trigger_schedule_expression  = "cron(12 20 * * ? *)"
}

locals {
  lambda-name = replace(regex("\\.*(.*)", "${var.certificate_domains[0]}")[0], ".", "-")
  certificate_domains = join(",", [ for domain in var.certificate_domains : regex("\\.*(.*)", domain)[0] ] )
}

data "aws_route53_zone" "zones" {
  for_each = toset( var.certificate_domains )

  name = regex(".*?[[:punct:]]*(.*)", each.value)[0] 
  private_zone = false
}

resource "tls_private_key" "stub" {
  algorithm = "RSA"
}

resource "tls_self_signed_cert" "stub" {
  private_key_pem = tls_private_key.stub.private_key_pem

  subject {
    common_name  = "${var.certificate_domains[0]}"
    organization = "ACME Examples, Inc"
  }

  validity_period_hours = 12

  allowed_uses = [
    "key_encipherment",
    "digital_signature",
    "server_auth",
  ]
}

resource "aws_acm_certificate" "cert" {
  private_key      = tls_private_key.stub.private_key_pem
  certificate_body = tls_self_signed_cert.stub.cert_pem
}

variables.tf

variable "aws_region" {
  type    = string
  default = "us-east-2"
}

variable "certificate_domains" {
  type = list
  default = [
    ".voximplant.com",
    "*.voximplant.com",
    ".voximplant.ru",
    "*.voximplant.ru"
  ]
  # Front dots should be used to allow automatic Route53 zone id detection for second level domains.
}

variable "certbot_contact_email" {
  type    = string
  default = "usik@voximplant.com"
}

aws_certified_cloud_practitioner

anonymous@undisclosed.example.com (Anonymous) — Fri, 18 Nov 2022 11:51:25 +0000

Тут я оставляю заметки при подгтовке к экзамену AWS Certified Cloud Practitioner - CLF-C01

1. Cloud Computing

Шесть преимуществ использования облаков

Бизнес тратится только на то что нужно для работы - капитальные вложения в инфраструктуру CAPEX (capital expense) превращаются в операционные расходы OPEX (operating expense) на облачные ресурсы.
Экономия на масштабе - вместо покупки инфрастурктуры по ритейловым ценам облачные провайдеры предлагают более низкие цены за счет масштаба и специализации.
Гибкое планирование. Необходимые ресурсы можно приобрести именно когжа они нужны и отказаться от них если они стали не нужны.
Скорость и гибкость. Вместо заказа, покупки, исталляции и эксплуатаци собственной инфрастурктуры можно получить то же самое в пару кликов и за несколько секунд.
Отсутствие затрат на датацентр, который надо строить, запитывать, охлаждать, мониторить и т.д.
Глобальность и отказоустойчивость. Облачные провайдеры готовы предоставить ресурсы в тех регионах, где они нужны - максимально близко к пользователям, а также - обеспечить отказоустойчивость на уровне глобаьных регионов.

Виртуализация vs Cloud Computing

Cloud Computing выгодно отличается от банальной виртуализации:

Развитые интерфейсы API для управления ресурсами
Наличие инструментов CLI
Возможность управлять более сложными ресурсами (базы данных, брокеры сообщений и т.д.), а не банальным виртуалкам.

Различные модели облачных ресурсов

IaaS - Инфрастурктура как сервис. То есть предоставление доступа к виртуальным аппаратным ресурсам, хранилищам и сетям.
Paas - Платформа как сервис. Предоставление ресурсов, решающих конкретные задачи в рамках решений работающих в облаке. То есть это managed базы данных, брокеры сообщений, объектные хранилища.
SaaS - ПО как сервис. Это законченные решения, предоставляемые конечным пользователям. Например - Microsoft Office 365 или Google Workspace.

2. Обзор глобальной инфраструктуры AWS

Регионы и зоны доступности

Регион (AWS region) - это большой кластер датацентров в пределах географического региона.
Зона доступности (Availability Zone) - это логически и физически сгруппированные датацентры в рамках региона. AZ удаленны друг от друга не более чем на 100 км для синхронной репликации.

Всего у AWS есть 77 зон доступности в 24 регионах (это наверное на 2021 год).
В каждом регионе есть две или более зоны доступности. Крупные регионы содержат до шести зон. Основным регионом считается N.Virginia - us-east-1. В нем сервисы появляются раньше всех.
Регионы позволяют:

Разместить ресурсы ближе к конечным потребителям, тем самым уменьшив задержки.
Обеспечить соотвествие местному законодательству в области хранения и обработки данных.
Обеспечить отказоустойчивость.

Зоны доступности позволяют:

Обеспечить отказоустойчивость в рамках региона (близкое расположение зон и хорошие каналы между ними позволяют использовать синхронную репликацию данных между сервисами в нескольких зонах).

Edge Locations

Они расположены близко к регионам (но не зависят от них).
Используются для кеширования наиболее востребованных статических ресурсов.
В том числе - и для кеширования объектов выгружаемых/загружаемых из/в хранилищ(а) S3 (Amazon S3 Transfer Acceleration).
Также - существуют Region Edge Locations в рамках регионов, которые обладают большими объемами.

Глобальные, Региональные и On-premises ресурсы

Объекты большинства сервисов привязаны к регионам. Например - если создается сервер или кластер базы данных, то при создании необходимо указать регион, а в дальнейшем указывать регион при обращении к данному объекту. Это связано с физической инфрастурктурой, задействованной в работе объекта.
Однако, есть и глобальные сервисы:

AWS IAM - сервис управления учетными записями и привилегиями.
Amazon Cloud Front - сервис CDN, используемый для доставки статичного контента. Запрашиваемы ресурсы динамически кешируются в наиболее близкой к потребителю локации.
Amazon Route 53 - DNS-сервис
Amazon S3 - бакеты в рамках сервиса привязаны к регионам, но сам сервис - глобален. То есть в консоли сервиса видны бакеты из всех регионов.

Сервисы размещаемые у заказчика (On-Premises) для создания гибридной инфраструктуры:

Amazon Snow Family - SnowBall Edge Devices, SnowCone и Snowmobile. Это сервис перемещения данных от заказчика в облако AWS. Заказчику привозят дисковые корзины, на которые он копирует данные, а потом они физически уезжают в облако AWS. Также предоставляются некоторые вычислительные ресурсы, для анализа и необходимой обработки копируемых данных.
Amazon Storage Gateway - по сути является кешем и предоставляет бесшовную интеграцию с облачным хранилищем S3. Приложения заказчика обращаются к Storage Gateway, а он - либо выгружает “холодные” данные на облако, тем самым расширяя доступный объем хранилища, либо, если скорости работы с облаком недостаточно - обеспечивает резервное копирование в облако.
Amazon Outposts - это стойки 42U (немного меньше стандартных 48U) с оборудованием и софтом для управления, совместимым с облачным AWS, но размещаемые в датацентре заказчика. На этом оборудовании могут рабоать как просто машины EC2, так и хранилища, базы RDS, а также - Elastic Container Services (ECS), Elastic Kubernetes Services (EKS), Elastic MapReduce (EMR).

Планы поддержки AWS

Basic

Только базовая поддержка по e-mail, в чатах и по телефону 24/7 при проблемах с аккаунтом, а также доступ к открытой документации и форумам.
Семь базовых проверок Trusted Advisor Tool. Мониторинг и оповещение через - Personal Health Dashboard

Developer

Рекомендуется для экспериментов и тестирования.
Базовая поддержка по технической части компонентов AWS и юзкейсам.
Только по e-mail в рабочее время.
Количество тикетов - не ограничено.
Время реакции - 24 часа для обычных вопросов и 12 часов для системных проблем. В остальном - то же что и в Basic-плане.

Business

Рекомендуется для продукционных сред.
Техническая поддержка по e-mail, в чатах и по телефону 24/7.
Время реакции - зависит от проблемы, но, к примеру, если упала продукционная система, то можно ожидать поддежки от Cloud Engineer в течение часа.
Работа с проблемами взаимодействия между сервисами AWS и сторонним ПО.
За дополнительные деньги доступен инструмент Infrastructure Event Management, который позволяет проанализировать инфрастурктуру, оценить её готовность и выявить риски перед серьезными мероприятиями типа запуска в прод или миграциями.
Доступен полный набор проверок Trusted Advisor и рекомендаций по их мотивам:

Cost Optimization
Security
Fault Tolerance
Performance
Service Limits

Enterprise

Начинается с $15000 в месяц.
Доступен персональный менеджер - Technical Account Manager (TAM), который активно мониторит состояние инфраструктуры и предлагает решения проблем.
Доступны Well-Archtected Review грамотными специалистами.
Техническая поддержка по e-mail, в чатах и по телефону 24/7.
Время реакции для business critical проблем - 15 минут.

Таблица

Basic	Developer	Business	Enterprise
Только нетехническая поддержка	по e-mail с 8:00 до 18:00 в TZ клиента	по e-mail, в чатах и по телефону 24/7	по e-mail, в чатах и по телефону 24/7
	Простая техподержка сервисов AWS. SLA - 24 часа	Простая техподержка сервисов AWS. SLA - 24 часа	Простая техподержка сервисов AWS. SLA - 24 часа
	Реакция на системные проблемы - 12 часов	Реакция на системные проблемы - 12 часов	Реакция на системные проблемы - 12 часов
		Реакция на проблемы продукционных систем - 4 часа	Реакция на проблемы продукционных систем - 4 часа
		Реакция на отказы продукционных систем - 1 час	Реакция на отказы продукционных систем - 1 час
			Реакция на отказы business-critical систем - 15 минут

AWS Personal Health Dashboard

Раньше была доступна на https://status.aws.amazon.com , а сейчаc редиректит на https://phd.aws.amazon.com
Показывает состояние сервисов во всех регионах.
Позволяет настроить какие-то реакции на события.

3. Управление аккаунтами

Amazon рекомендует создавать столько учеток, сколько необходимо. Для эффективнго управления учетками предуемотрен ряд инструментов.
Использование мультиаккаунтного подхода позволяет:

Обеспечить административное разделение ресурсов для лучшего контроля и планирования.
Обеспечить явную изоляцию ресурсов и исключить их взаимное автообнаружение.
Устранить избыточные манипуляции с учетками пользователей. Например - вместо того, чтобы создавать отдельные дублирующие учетки пользователей в каждом проекте AWS, можно слить учетки всех пользователей в одну AWS Identity Management Account и раздавать права с помощью cross-account разрешений и политик.
Обеспечить изолированные учетки для аудита или восстановления.

AWS Landing Zone

AWS Landing Zone - уже устаревший инструмент, замененный AWS Control Tower. Представляет собой гайдлайн для планирования и реализации лучших практик мультиаккаунтного окружения.

AWS Control Tower

Данный инструмент позволяет создавать мультиаккаунтные окружения (landing zones) с помощью шаблонов, включающих следующие элементы:

Собственно сама AWS Organization и многоучеточное окружение
Настраивать SSO
Федерацию различных каталогов с помощью SSO
Централизованное логирование

Окружение, созданное с помощью AWS Control Tower использует рекомендуемые политики и подходы - guardrails.

AWS Organization

AWS Organization - бесплатный сервис, для централизованного управления учетками.
Каждый инстанс сервиса AWS Organization содержит одну основную management (master) учетку и позволяет создать учетки пользователей.
Сходные по функционалу учетки могут быть объединены в Organization Unit и управляться как единое целое.
К OU-шкам (или отдельным учеткам) могут применяться Service Control Policies. котрые определяют конкретные права на ресурсы.

Consolidated Billing

AWS Organization позволяет централизованно следить за расходами на ресурсы для каждой учетки отдельно и вцелом для всех учеток.
Отвественной за платежи является вляделец management-учетки.
Объединение счетов позволяет поользоваться скидками за большие объемы ресурсов.

Планирование архитектуры учеток

Иерархия учеток (и распространения привилегий) строится на нескольких простых принципах:

Политики примененные к OU-шке распространяются на вложенные элементы - OU-шки и учетки в них
У каждой OU-шки может быть только одна родительская OU-шка.
Каждая учетка может входить только в одну OU-шку.

Обязательно должны существовать пара OU-шек с учетками:

Infrastructure Services - учетки для доступа к общим инфраструктурными сервисам - сетевым, репам образов и прочее.
Security Services - OU-шка с учетками для доступа к логам и security-сервисам

Вообще - нихрена непонятно на первый взгляд. Надо почитать тут: https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/recommended-ous.html

AWS Free Tier Accounts

AWS Free Tier Account - обычная стандартная учетка, которая имеет досступ ко множеству сервисов AWS бесплатно 12 месяцев с момента регистрации. С ограничениями по потребляемым ресурсам.
Также - есть доступ к ряду инструментов и сервисов:

AWS Cloud Formation - сервис и тулзы для IaC.
Amazon Elastic Beanstalk - сервис оркестрации, который создает и настраивает ресурсы (например - S3 и балансировщики) под нужды приложения. Разработчику достаточно залить код, а Amazon Elastic Beanstalk создаст необходимую для работы приложения инфраструктуру. Сам сервис - бесплатен, но ресурсы им создаваемые - нет!

Вечнобесплатные сервисы

Сервисы, в которых можно создавать бесплатные ресурсы (с учетом некоторых ограничений):

Amazon CloudWatch - сервис для мониторинга ресурсов и приложений. Бесплытные - 10 метрик, 10 оповещений и миллион вызовов API.
Amazon Lambda - бессерверные вычисления. Кода, запускаемый в ответ на события. Бесплатно - миллион вызовов API и 3.2 миллиона секунд машинного времени в месяц.
AWS Organizations

Пробные бесплатные сервисы

Сервисы с бесплатным пробным 30-девным периодом:

Amazon Workspaces - сервис VDI (Windows и Linux). Стандартный план предполагает две виртуалки 80GB на систему и 50Gb на данные. В месяц - 40 часов. Период - два месяца.
Amazon Detective - сервис оценки и визуализации потенциальных проблем с безопасностью.
Redshift - сервис хранения и анализа больших объемов структурированных и неструктурированных данных. 2 месяца триал включает ежемесячные 750 часов работы инстанса DC2.Large.

4. Технологии AWS

Identity and Access management - IAM

В иерархии IAM есть соедующие учетки:

root user - основная учетка аккаунта. Не должна использоваться для повседнейвных операций.
additional users - непривилегированные пользователи, имеющие набор привилегий, свойственный их задачам. А также - сервисные учетки для автоматизации.

Двухфактораня аутентификация - MFA

Позволяет защитить учетки от подбора или воровства паролей.
Используют принцип - для аутентификации должны использоваться две сущности - одна которую пользователь знает (пароль), вторая - нечто что принадлежит пользователю и есть у него прямо сейчас (источник второго фактора SMS или OTP).
Управление вторым фактором происходит в разделе Secure Credentials.

Политики паролей

Настраивают сложность паролей.
Настройки в разделе Account Settings (в меню справа в консоли IAM)

IAM Access Keys

Подобны паре логин-пароль и используются для программного (из aws cli или SDK) доступа к платформе (в отличие от логина-пароля и второго фактора, используемых при доступе к web-консоли).
Каждая пользовательская учетка может иметь два access key.

IAM Groups

Позволяют объединять пользовательские учетки в группы и назначать привилегии (привязывать политики) на группу, что имеет эффект на всех пользователей в группе.
Добавление пользователя в группу распространяет на него все политики. привязанные к этой группе.

IAM Roles

Если используются сервисные пользовательские учетки, то для повышения безопасности могут понадобиться механизмы ротации учетных данных.

Назначение привилегий с помощью политик IAM

Политики представляют собой json-документы.
Политики позволяют реализовать принцип “наименьших привилегий” (least privileges) и давать необходимый минимум прав.
Когда пользователь обращается к ресурсу, то IAM вычисляет результирующую политику для его учетки и ролей этой учетки и принимает решение о предоставлении доступа.
Шесть типов политик:

Identity-based - эти политики привязываются к пользователям, группам и ролям и дают им права. Действуют в рамках аккаунта (то есть невозможно привязать политику к пользователю из другого аккаунта), однако - можно назначить роль пользователю из другого аккаунта. Таким образом - реализовать авторизацию внешних пользователей для доступа к ресурсам вашей учетки.
Resource-based - политики привязываются к ресурсам. В них прописано какие пользователи (группы, роли) имеют доступ к данному ресурсу. Анонимный доступ - *.
Permission Boundaries - привязываются к юзеру или роли и задают максимум привилегий, которе могут быть заданы с помощью Identity-based-политик.
Organization Services Control Policies (SCPs) - задают максимальный уровень привилегий для пользователей в организации. Сами по себе не дают никаких прав, но задают максимально доступный ровень.
Access Control lists - задают права для доступа к конкретным экземплярам ресурсов (например - бакетам S3) для внешних (не находящихся в данном аккаунте) пользователям и ролям. Похожи на Resource-based-политики, но задаваемый в ACL набор привилегий ограничен. ACL представляют собой не json-документы.
Session Policies - позволяют дать прав конкретной сессии про программном доступе.

Типы Identity-based политик

В свою очередь Identity-based-политики делятся на:

Managed AWS Policies - дефолтные политики, которые создает AWS и управляет ими. Задают типичные привилегии. КОнечные пользователи не могут их изменить.
Customer Managed Policies - политики, которые создает и редактирует пользователь.
Inline policies - политики, существующие как часть субъекта IAM (пользователя, группы или роли) и неотделимы от него. Эти политики существуют, пока существует субьект IAM.

Пример политики

{
  "Version": "2012-10-07",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "*"
    }
  ]
}

Version - всегда “2012-10-07”
Statement - собственно список параметров (объектов и разрешений) политики
Effect - что политика делает. Разрешает или Запрещает.
Action - список действий.
Resource - ARN ресурса (или вайлдкард как тут).

ARN - Amazon Resource Name

Может быть в форматах:

arn : partition : service : region : account-id : resource-id
arn : partition : service : region : account-id : resource-type/resource-id
arn : partition : service : region : account-id : resource-type : resource-id

partition - Группа клиентов AWS. Для большинства стандартных клиентов - aws. Для Китая - aws-cn. Могут быть и другие
service - название сервиса (продукта) AWS. s3 или acm и т.д.
region - Регион, где существует данный ресурс. Для глобальных сервсов может быть и пустым, тогда заменяется на дополнительную :.
account-id - 12-знаковый номер учетки, в которой создан ресурс. Может быть пустым, тогда заменяется на дополнительную :.
resource-type - тип сесурса - user или instance и т.д
resource-id - имя (идентификатор) ресурса
Condition - дополнительные условия применения политики. Например - для ограничения доступа с определенных IP-адресов.

IAM Policy simulator

Тулза для проверки политик: https://policysim.aws.amazon.com
Там все просто:

слева вибираешь пользователя, видишь привязанные к нему политики и можешь их включать/отключать
справа выбираешь сервис и действие.
жмешь Run Simulation, чтобы увидеть deny или allow

Получение привилегий с помощью ролей

Пользовательские учетные записи - это идентификаторы, назначенные людям или сервисам (для программного доступа к ресурсам).
В то же время роли - могут рассматриваться как самостоятельный тип идентификаторов, имеющих собственный набор политик и привилегий. Роль может быть назначена субъекту для выполнения некоторых задач.
Например:

Экземпляру сервиса AWS можно назначить роль для доступа к экземплярам других сервисов в пределах данного аккаунта. Например - инстансу EC2 для работы с базой данных.
Пользователю из одного аккаунта можно назначить роль для доступа к ресурсам другого аккаунта.
Учетной записи пользователи из внешних провайдеров (Active Directory LDAP, OpenID Google,facebook или Amazon) можно назначить роль и тем самым дать прав на заданные сервисы и ресурсы в аккаунте AWS. При этом создавать учетку пользователя в аккаунте AWS не нужно.

Автоматическое обновление учетных данных при использовании ролей

Одним из ключевых свойств ролей является автоматическая ротация учетных данных при доступе внешних пользователей к ресурсам.
Таким образом - исключается долговременное хранение учетных данных на клиентах и обеспечивается нужный уровень безопасности.
Данный функционал обеспечивает Security Token Service (STS), который выдает обновляемые короткоживущие токены при назначении роли, а также контролирует их прозрачное.
Временные учетные данные включают в себя:

access key ID
secret access key
security token

Вот этот самый security token и есть обновляемая короткоживущая часть кредов.
При создании роли содается политика доверия (trust policy), которая описывает субъектов, имеющих право получить данную роль. Кроме того, субъект должен иметь разрешение на получение данной роли.
Использование ролей - предпочтительный способ назначения привилегий, вместо создания отдельных учеток для внешних пользователей.

Отчеты об использовании учеток

AWS позволяет строить различные отчеты об учетных записях и выгружать их в CSV

Работа с инструментами AWS CLI

Инструменты командной строки могут значительно ускорить работу с сервисами AWS, позволяя одной командой выполнять довольно сложные манипуляции, а также обхединять множество действий в скрипты.

Настройка доступа к сервсам AWS через AWS CLI

Следует избегать использования root-учетки для работы с CLI, поскольку учетные данные в этом случае хранятся локально.

Установка инструментов AWS CLI

Надо скачать и установить отсюда: https://aws.amazon.com/cli/

Первичная настройка инструментов AWS CLI

После установки надо запустить:

aws configure

И предоставить следующие данные:

access key ID
secret access key
дефолтный region

В итоге - эти данные попадут в файл ~/.aws/credentials:

[default]
aws_access_key_id = ...............
aws_secret_access_key = ............

В данном случае [default] - это имя профиля AWS. Их может быть несколько, а переключаться между ними можно задавая значение переменной AWS_PROFILE:

export AWS_PROFILE=another_profile

5. Amazon Simple Storage Service (S3)

Amazon S3 - надежное объектное хранилище. Надежность на уровне “11 девяток”.
Объекты организованы в контейнеры - бакеты. Внутри контейнера струкрутры нет.
Имена бакетов должны быть уникальны в пределах всей инфраструктуры AWS.
Доступ к объектам (файлам) бакета может быть осуществлен одним из способов:

Virtual hosted-style endpoints: https://___BUCKET_NAME___.s3.amazonaws.com/___FILE_NAME___
Website endpoint: s3-website -(dash) Region (http://___BUCKET_NAME___.s3-website-Region.amazonaws.com/___FILE_NAME___) или s3-website .(dot) Region (http://___BUCKET_NAME___.s3-website.Region.amazonaws.com/___FILE_NAME___)

Максимальный размер объекта в Amazon S3 - 5Tb (терабайт).
Имя файла (объекта) обычно называется key, а его содержимое - value

Имена бакетов

уникальны в пределах всей инфраструктуры AWS
не менее 3 и не более 63 символов длиной
могут содержать только маленькие буквы, цифры, точки и тире
могут начинаться только с цифры или буквы
не могут быть подобны IP-адресам (192.168.1.1 - не валидно)
бакеты, доступ к которым происходит с помощью Amazon S3 Transfer Acceleration не могут содержать в названии точки.
Бакеты не могут быть вложенными.

Точки в именах могут использоваться только при Web-style доступе, который осуществляется по незащищенному протоколу HTTP. Virtual hosted-style endpoints предполагает использование HTTPS и имена с точками не проходят через SNI. Если совершенно необходимо использовать точки в именах бакетов при доступе по HTTPS, то можно использовать какой-то балансировщик, который будет терминировать SSL. Например - Amazon Cloud-Front.

Имена ключей (объектов, файлов)

длина до 1024 байт
Могут содержать буквы, цифры и спецсимволы - !-_.*()

Организация объектов в бакете

В интерфейсе есть кнопка Create folder, которая позволяет создать как-бы иерархию директорий в бакете, однако структура объектов всё-равно остается плоской.
Это достигается за счет использования префиксов (имен директорий) и разделителей / в именах ключей. То есть ключ (имя объекта в бакете) может содержать в себе привычную структуру директорий, которая отобразится в интерфейсе.

Префиксы и скрость доступа к объектам

AWS ограничивает IOPS не на уровне бакета, а на уровне префиксов. То есть если вам доступны 5500 IOPS для методов GET/HEAD, то для получения скорости на уровне 27500 IOPS достаточно использовать 5 различных префиксов в именах ключей.

Регионы размещения данных S3

При создании бакета обяхательно указывать регион, где данные физически будут расположены.
AWS НИКОГДА не реплицирует данные в другие регионы. Физически данные всегда в том регионе, где создан бакет. Однако, пользовватель может настроить репликацию в другой бакет в другом регионе.

Права доступа к объектам в S3

По дефолту - права на объекты в бакете есть только у создавшей его учетки.
Основных способов раздачи прав на объекты S3 два:

resource-based-политика (bucket-policy)
Списки доступа (ACLs)

Также ограниченно могут использоваться IAM-политики.
Deny - всегда сильнее, чем Allow. Но взаимоисключающими не являются.

Бакет-полиси

JSON-документ.
Раздает права (в том числе и анонимный доступ) как на саму корзинку, так и на объекты в ней.
Могут давать права юзерам и ролям из других аккаунтов.

Списки доступа

Считаются legacy и вместо них всегда лучше использовать политики.
Не могут давать доступ отдельным юзерам (только аккаунту целиком).
Есть случаи, когда ACL всё еще используется

IAM политики

На первый взгляд - могут использоваться для раздачи прав на ресурсы S3. Однако - не могут быть привязаны напрямую к ресурсу.
Вместо этого - следует создавать роль, давать ей права на ресурсы S3, создавать политику доверия (чтобы пользователь мог принять роль).
Также - IAM-политики не могут использоваться для раздачи анонимного доступа, так как всегда должны быть привязаны к какому-то субъекту (айдентити).

Классы хранилищ S3

различаются по следующим параметрам:

Скорость доступа
Постоянная/непостоянная доступность
Стоимость

Стоимость в свою очередь определяется параметрами:

Стоимость собственно хранения (в долларах в месяц за гигабайт)
Количество запросов на запись/извлечение
использование ускорения доставки
использование обработки и аналитики, в том числе и Lambda-функциями
возможность потери части данных

Стоимость закачки данных В S3 - бесплатно!
важно понимать, что в пределах одного бакета могут храниться объекты на хранилищах разных классов. То есть создавать для каждого класса отдельный бакет не нужно.

Классы хранилищ S3 для объектов частого доступа

Amazon S3 Standard - дефолтный класс. Обеспечивает 11 девяток надежности и 4 девятки доступности. Данные реплицируются как минимум на три зоны доступности в регионе.

Классы хранилищ S3 для нечастого доступа

Хранение стоит дешевле, однако есть плата за извлечение. Минимальный размер обхекта - 128kB (То есть даже пустой файл занимает 128kB).

Amazon S3 Standard Infrequent Access (S3 Standard IA) - для хранения важных, но нечасто нужных данных. Идеальны для бекапов или Disaster Recovery
Amazon S3 One Zone Infrequent Access (S3 One Zone IA) - Данные хранятся только в одной AZ в регионе. Доступность падает до 99.5%. Если в зоне проблемы - данные могут быть некоторое время недоступны. Теоретически - возможны безвозвратные потери. Рекомендуется для вторых бекапов и восстановимых данных.

Архивные классы хранилищ S3

Не предполагают мгновенного доступа к данным, а доступ по запросу - извлечение может занимать от нескольких минут, до 12 часов и более.

Amazon Glacier - для долговременного хранения и нечастого достап по запросу. Данные подготавливаются в течение нескольких часов (до 12).
Amazon Glacier Deep Archive - самый недорогой способ хранения старых данных. Извлечение может занимать 12 часов и более.

Amazon Intelligent Tiering

Класс хранилища Intelligent Tiering мониторит частоту обращений к обектам и делает следующее:

Если объект не запрашивался 30 дней - его класс хранения изменяется на более дешевый Standard IA
Опционально можно подключить и архивные классы хранения. Объекты не запрашиваемые 90 дней - переезжают в Amazon Glacier. А после 180 дней - Glacier Deep Archive.

S3 в Amazon Outposts

Amazon Outposts - 42U стойки с железом на площадке заказчика с AWS-совместимым набором управляющего софта.
При использовании аутпостов доступен еще один класс хранения - S3 Outposts.
S3 Outposts позволяет:

хранить от 48 до 96 терабайт данных
до 100 бакетов на 1 аутпост

AWS S3 Versioning

Защита от случайного (нежелательного) удаления/изменения объектов.

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

После включения версионирования - выключить его невозможно. Но можно приостановить.

S3 Replication

Асинхронная репликация данных между бакетами бывает двух видов:

Cross-Region Replication (CRR) - для обеспечения лучше йдоступности данных или отказоустойчивости
Same-Region Replication (SRR) - для аггрегации данных из нескольких бакетов в один или репликациями между окружениями (dev - prod)

Для работы репликации должно быть включено версионирование.
Реплицировать можно как бакеты одного аккаунта, так и между аккаунтами. Также - реплика может иметь другой класс хранения.
Можно реплицировать из одного бакета во многие. И наоборот - из многих - в один.

Amazon S3 Lifecycle Management

Механизм оптимизации стоимости хранения данных.
Может быть применен к бакету или просто набору объектов с помощью префикса.
Настраиваются правила. Два типа действий:

изменение класса хранилища в зависимости от востребованности данных
удаление, когда данные остаются невостребованными по истечение некоторого срока

Шифрование S3

Данные могут храниться в зашифрованном виде.
Шифрование может происходить как на стороне клиента, так и на стороне сервера Amazon S3.
При шифровании на стороне клиента - все заботы о шифровании/дешифровании лежат на клиенте.
при шифровании на стороне сервера возможны три взаимоисключающих механизма:

Server-side Encryption with Amazon S3 Managed Keys - SSE-S3. Каждый объект шифруется уникальным ключем, а ключи в свою очередь шифруются master-ключем. AWS автоматически управляет ключами и ротирует их.
Server-side Encryption with Customer Managed Keys - SSE-CMKs. Ключи хранятся в AWS Key Management Service (SSE-KMS). То же самое, что и SSE-S3, только можно управлять ключами и аудировать их использование.
Server-side Encryption with Customer Provided Keys - SSE-CPKs. Amazon S3 шифрует данные с помощью предоставленных клиентом ключей. Идеально для соотвествия регуляторным требованиям.

Хостинг статических ресурсов на AWS S3

Файлики можно хостить на S3, предоставляя к ним анонимный доступ.
Таким образом можно хостить как просто файлы, так и целые сайты.

Amazon S3 Transfer Acceleration - S3TA

Позволяет ускорить доступ клиентов к объектам в AWS S3 с помощью Amazon Cloud Front Edge Locations - точек доступа к AWS S3 (как на аплоад, так и на скачивание).

Amazon Glacier

Хранит данные в виде архивов zip или tar.
В одном архиве может быть либо один либо несколько объектов.
Размер одного архива - до 40 ТБ (при том что один объект может быть размером до 5ТБ).

Amazon Storage Gateway

Программное решение (виртуалка). Таже доступно в виде предконфигурированного физического сервера.
Обеспечивает прозрачный доступ к данным на инфрраструктуре AWS S3.
Виртуалки устанавливаются на стороне заказчика, а для доступа к данным серверы заказчика обращаются по протоколам:

NFS/SMB
Virtual Transport Layer (VTL)
iSCSI

Сам Amazon Storage Gateway подключается к AWS S3 через интернет с помощью IPSec VPN или AWS Direct Connect. Сценарии использования:

File Gateway - позволяет обращаться к файлам по протоколу SMB/NFS. Данные также кешируются локально. Хранятся либо в AWS S3, либо - Amazon FSx.
Volume Gateway - позволяет создавать тома, доступные по iSCSI. Может работать в режимах Cache mode, когда локально хранятся только “горячие данные” остальное ассинхронно реплицируется на S3. Stored Mode - все данные тома хранятся локально и ассинхронно реплицируются на S3 для бекапа. Tape Gateway - предоставляет интерфейс к виртуальным ленточным библиотекам для бекапов (которые лежат на S3).

Миграция больших объемов данных

Иногда данных много и залить их через интернет в облако невозможно.
Тогда на помощь приходят продукты Snow Family

Amazon SnowBall

Программно-аппаратные комплексы двух видов:

SnowBall Edge Computing Optimized - для обработки данных перед миграцией. 52vCPU, 208Gb Ram, опционально Nvidia Tesla, 42Tb HDD, 7.68 SSD.
SnowBall Edge Storage Optimized - чисто для данных. 80Тб HDD, 1Tb SSD, 40vCPU, 80Gb RAM

Amazon SnowCone

Малленький девайс. 2 кг. 8Тб диск, пара ядер CPU и 4 Gb RAM.

Amazon SnowMobile

Для эксабайтных масштабов.
Приезжает 45-футовый защищенный контейнер.
До 100 Петабайт данных. С полной технической поддержкой миграции.

6. Сетевые сервисы AWS - VPC, Route53, CloudFront

VPC

AWS VPC - это виртуальная облачная сеть.
Область действия VPC - в пределах Региона AWS. То есть ресурсы могут размещаться в любой AZ региона.
При создании VPC нужно задать один из диапазонов адресов для частных сетей.

Подсети VPC (Subnets)

Внутри VPC должны быть созданы подсети с непересекающимися диапазонами адресов.
То есть если VPC назначен CIDR 10.0.0.0/16, то подсети могут иметь CIDR - 10.0.1.0/24 и 10.0.2.0/24 .
Каждая подсеть существует в пределах одной зоны доступности (AZ).

Доступ в Internet

У дефолтных VPC и подсетей доступ в интернеты есть.
Чтобы у кастомных VPC был доступ в интернет - должен быть задеплоен шлюз (internet gateway) и соответствующие маршруты.
С публичными адресами история такая:

автоматически назначаемые публичные адреса нестатичны и могут меняться после рестарта машины.
если динамические публичные адреса не подходят, то нужно прописывать Elastic IP Address

Elastic IP Address

Статичные. Существуют пока существует аккаунт.
Могут быть переданы от одного инстанса EC2 к другому.
Бесплатны, но только пока запущена машина EC2 с этим адресом. Если инстанс остановлен - за адрес взымается почасовая оплата.

VPC Security

Обеспечение безопасности - одна из основных функций VPC.
Достигается - правилами файерволов, отделяющих одни подсети от других.
Имеются два механизма реализации безопасности:

Security Groups
Network Access Control Lists (NACLs)

Security Groups

Это наборы правил файервола для входящего и исходящего трафика, которые привязываются к инстансам EC2.
Работают именно на уровне инстансов, но не подсетей.
К каждому инстансу должна быть привязана хотя бы одна Security Group.
Максимум можно привязать пять Security Group к одному инстансу EC2.
Дефолтные Security Group разрешают любые исходящие подключения, а входящие подключения только от инстансов с такой же Security Group.
Важно понимать, что Security Groups являются statefull, что означает что если разрешен входящий трафик к какому-то сервису, то автоматически разрешается и ответный (исходящий) трафик сервиса, независимо от явно заданных исходящих разрешений.
Несколько важных свойств Security Groups:

Конфигурируются только правила allow. Правил deny просто нету.
Отдельные правила для входящего и исходящего трафика.
Трафик фильтруется по протоколам и портам.
В правилах в качестве source/destination могут быть заданы как диапазоны IP-адресов, так и другие Security Groups

Network Access Control Lists (NACLs)

Это другой тип правил файервола - ограничивает трафик к целым подсетям.
По-дефолту - разрешено всё, поскольку ограничения действуют на уровне Security Groups
Не являются statefull, что означает необходимость явно конфигурировать как правила для входящего трафика к сервисам, так и ответного исходящего от сервисов.

Трансляция адресов - NAT

Для предоставления доступа в интернет для инстансов, работающих в непубличных (не имеющих прямой связи с интернетом) сетях используется NAT.
Сервис NAT должен быть помещен в публичную сеть и иметь Elastic IP.
Должны быть сконфигурированы соответсвующие маршруты.
Если инстансы используют IPv6, то доступ в интернет для них настраивается с помощью egress-only internet gateway.

Связь между разными VPC - VPC peering

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

VPC tansit gateway

Если число взаимодейтсвующих VPC больше двух, то сетевая топология может быть довольно сложной.
Для ее упрощения существует VPC transit gateway, реализующий топологию “звезда”.

Virtual Private Networks - VPN

К инфраструктуре AWS можно подключить on-premise ресурсы с помощью IPSec VPN.
Для этого надо создать и настроить Virtual Private Gateway и подключить его к VPC.
На стороне on-premise поддерживаются различное оборудование - Cisco, Juniper, Check Point и прочие.
После настройки собственно канала - нужно настроить маршруты.
Существует аппаратное ограничение на скорость зашифрованного IPSec VPN - 1.26 Gbps.

AWS Direct Connect

Способ подключения on-premise инфраструктуры AWS по выделенным каналам.
Это дорого и круто - прокладывается оптика до ближайшего узла партнеров Amazon Direct Connect.
Доступны скорости подключения до 100 Gbps.

AWS Route53 - глобальный DNS и роутинг

Основные функции AWS Route53:

Регистрация доменных имен
DNS-роутинг
Health-чеки

Регистрация доменных имен

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

Hosted DNS-зоны Route53

Для создания DNS-записей, указывающих на ресурсы надо создать Hosted Zone.
Hosted Zone - это контейнер для хранения записей и управления ими.
Существует два типа зон AWS Route53:

Public hosted zone - зоны доступные из интернета и предназначены для роутинга входящего трафика из интернета.
Private hosted zone - частные зоны доступные только внутри VPC.

DNS-имена ресурсов AWS

При создании ресурса он получает DNS-имя, которое доступно с помощью Amazon Route53 Resolver.
Существуют два типа DNS-записей ресурсов:

Private DNS hostnames - указывают на приватный IP-адрес ресурса внутри VPC. Имеют вид - ipv4-private-address.ec2.internal (в us-east-1) и ipv4-private-address.region.compute.internal (в остальных регионах).
Public DNS hostnames - указывают на публичный IP-адрес ресурса в интернете. Имеют вид - ipv4-public-address.compute-1.amazonaws.com (в us-east-1) и ipv4-public-address.region.compute.amazonaws.com (в остальных регионах).

Политики маршрутизации Route53

Simple routing policy - один ресурс, одна запись. Состояние ресурсов не контролируется
Failover routing policy - Одна запись указывает на несколько (основной и резервные) экземпляры ресурсов, а их состояние контролируется health-чеками. Схема Active-Passive
Geolocation Routing Policy - При поступлении DNS-запроса от клиента - по его IP определяется его географическое положение и он направляется на блжайший к нему ресурс.
Latency Routing Policy - маршрутизация на основе сетевых задержек. Позволяет обеспечить доступ к ресурсам с минимальными задержками.
Weighted routing policy - позволяет направить указанные доли запросов на заданные ресурсы. Используется для регулирования нагрузок при миграциях.

Health Checks

Проверки состояния ресурсов.

Проверки состояния эндпонитов. Мониторят указанный эндпоинт (DNS-имя или ip-адрес)
Проверки состония других health-чеков. Проверка общего состояния пула ресурсов. Позволяют задать пороговые значения доступности для группы эндпоинтов и выполнять действия, если количество работоспособных эндпоинтов ниже заданного.
Реакция на события CloudWatch - Cloudwatch может мониторить метрики приложений (например - количество доступных инстансов за балансировщиком). В свою очередь - Route53 может мониторить тот же поток данных, что и CloudWatch и независимо от него реагировать (например - помечать ресурс как unhealthy в зависимости от количества доступных метрик). Для реакции даже не обязательно, чтобы CloudWatch переходил в состояние Alarm - Route53 анализирует данные и автономно.

Политики обработки трафика - Traffic flow policies

Политики роутинга могут быть довольно сложными.
Например - можно по Latency роутить трафик между несколькими регионами, затем - по Weighted между инстансами.
Каждая такая конфигурация - является собственно политикой траффика, которая создается с помощью визуального редактора Route53.
Важно понимать, что политики трафика Route53 могут быть созданы только для публичных DNS-зон.
Дополнительно к основным политикам доступны следующие:

Geoproximity routing policy - роутинг трафика в зависимости от географического расположения ресурсов и клиентов.
Route53 Resolver - позволяет создавать правила и форвардить запросы получаемые Route53 DNS на DNS-серверы on-premise.

Организация CDN с помощью Amazon CloudFront

Amazon CloudFront предоставляет инструменты для организации динамической сети распространения контента CDN.
Запрашиваемые объекты доставляются с помощью Edge Locations (и кешируются там), расположенных наиболее близко к клиенту.
Для включения этого функционала надо создать distribution endpoint и задать источник (бакет S3, инстанс ec2, балансер) и тип контента.
В результате получится URL (HTTP или HTTPS), который можно отдавать пользователям.
Контент может быть:

статика (HTML, CSS, JS, картинки)
Видео в различных форматах
Live-контент - видеоконференции и прочее.

Выбор класса для CloudFront distribution

Стоимость дистрибуци трафика зависит от качества инфраструктуры в регионе.

Дефолтный и самый дорогой класс дистрибуции - глобальный, когда контент может быть кеширован на любом из существующих EdgeLocation.
Второй по стоимости класс включает только регионы USA,Canada, Europe, Hong Kong, Philippines, South Korea, Taiwan, Singapore, Japan, India, South Africa, Middle East.
Самый недорогой класс включает только регионы - USA, Canada, Europe.

Amazon API Gateway

Managed-сервис для создания быстрых и безопасных API, предоставляющих доступ к облачным ресурсам - базам данных, микросервисам, Lambda-функциям и прочим.
API создается путем описания высокроуровневых абстракций.

7. AWS Compute Services

Инстансы EC2

Инстансы делятся на:

семейства (family) - по типу нагрузки. Например - general-purpose
В пределах семейства существуют типы (types) - определяющие конкретные свойства предоставляемого аппаратного обеспечения. Например - T2 или M5
В пределах каждого типа доступны разные размеры (sizes) - определяющие конкретные объемы предоставляемых ресурсов. Например - t2.micro (1vCPU, 1GiB RAM) или t2.xlarge (4vCPU, 16GiB).

Инстансы привязаны к конкретным зонам доступности (AZ). То есть при создании инстанса нужно указать подсеть VPC, которая как раз и привязана к AZ.
Каждый инстан может иметь:

один или несколько дисков (томов) EBS (Elastic Block Storage)
один или несколько сетевых адаптеров (NICs)

При создании инстанса используеся какой-то образ ОС - Amazon Machine Image (AMI).

Семейства инстансов

General Purpose - сбалансированные конфигурации для различных нагрузок.
Compute Optimized - для высокопроизводительных вычислений. HPC.
Memory Optimized - оптимизированы для нагрузок, активно использующих оперативную память.
Accelerated Computing - инстансы с аппаратными ускорителями (GPU и другие).
Storage Optimized - оптимизированы для нагрузок, требующих больших объемов и постоянной высокой пропускной способности локального хранилища.

Также доступны выделенные виртуалки и хосты - Dedicated Instances и Dedicated Hosts. Они нужны для соответствя регулятивным нормам, когда недопустима работа ПО на разделямых аппаратных ресурсах.

Dedicated Instances - виртуалки, работающие на хосте, который используется только одним заказчиком.
Dedicated Hosts - хост, используемый только одник заказчиком. Может быть полезен, когда прикладное ПО лицензируется на каждый процессор или сокет.

Amazon Machine Images (AMIs)

AMIs - образы дисков виртуальных машин.
Бывают двух типов:

снепшот диска EBS
целиком инстанс (Instance). Например AMI macOS будет в виде аппаратного Mac-mini.

Если в составе AMI есть лицензируемуе ПО, то стоимость лицензии входит в стоимость эксплуатации инстанса.
AMI существуют в пределах региона. То есть если нужно создать инстанс с заданным AMI - то этот AMI должен существовать в этом регионе. Однако - AMI можно копировать между регионами.
Источники AMI:

AWS Marketplace - образы, поддерживаемые AWS. В том числе и от внешних вендоров - Citrix, F5, Oracle и других. Стоимость инстанса складывается из стоимости собственно аппаратуры инстанса EС2 и стоимости лиценции ПО.
Community AMIs - образы, соданные сообществом. Поставляются as-is.
Можно создавать свои AMI для быстрого разворачивания и распространять их.

Amazon Elastic Block Storage

Тома подключаются к инстансам как правило по iSCSI.
Тома независят от инстансов и могут быть отсоединены и присоединены к другому инстансу.
Можно создавать снепшоты. Первый - полный, последующие - инкрементные. Снепшоты можно копировать между регионами и между аккаунтами.

Есть две категории дисков EBS:

SSD - ориентированы на высокие IOPS
HDD - могут дать высокую линейную скорость.

В свою очередь SSD также имеют типы:

gp2 - дефолтный тип. Подходит для большинства нагрузок. Размеры - от 1GB до 16TB. До 16000 IOPS. Надежность 99.9%. Минимальный уровень производительности - 3 IOPS/GB, минимум - 100IOPS, Масимум - 3000 IOPS для томов меньше 1TB.
gp3 - более новая версия general-purpose томов. Обеспечивает 3000 IOPS и 125MB/s для томов любого размера. За дополнительную плату можно получить 16000 IOPS. Размеры - от 1GB до 16TB. Отлично подходит для SQL-баз данных.
io1 - Быстрые SSD-диски. Размеры - от 4GB до 16TB. От 50 IOPS/GB, до 64000 IOPS. До 1000 MB/s. Максимум производительности достижим для инстансов на базе AWS Nitro.
io2 - последняя версия SSD EBS томов. 100X надежности (99.999%) и 10X производительноси - 500 IOPS/GB Размеры - от 4GB до 16TB. Хорош для любых высоких нагрузок. До 64000 IOPS и 1000 MB/s для инстансов на базе AWS Nitro.
io2 Block Express - 4X относительно io2. 4000 MB/s, 256000 IOPS, 1000 IOPS/GB. Размеры - от 4GB до 16TB.

HDD представлены типами:

st1 - low-cost HDD. При базовой производительности 40 MB/s на 1TB, могут выдавать до 250 MB/s на 1 TB объема. Максимальная скорость - до 500 Mb/s. Размеры - от 125GB до 16TB. Не могут быть загрузочными томами. Типичные нагрузки - MapReduce, Kafka, логи и прочее.
sc1 - Cold HDD. Самый медленные и дешевые тома. В базе выдают 12 МB/s на 1 TB объема. До 80 MB/s на 1 TB. Максимальная скорость - до 250 Mb/s. Размеры - от 125GB до 16TB. Не могут быть загрузочными томами.

Тома AWS EC2 Instance store (Ephemeral storage)

Еще один тип хранилища - instance store представляет собой временный диск, размещенный на локальном диске фзического хоста, на котором работает инстанс EC2.
При выключении машины - этот том уничтожается, а при старте - снова создается (поскольку машина практически никогда повторно не стартует на том же хосте).
Такми образом - instance store - это временное хранилище, обеспечивающее минимальные задержки, по сравнению с EBS (который всегда SAN).
Важно понимать, что перезагрузка инстанса не приводит к уничтожению ланных на instance store, поскольку в этом случае машина остается запущенной на прежнем хосте и не переезжает на новый.
Надежность instance store - не гарантируется.

Цены на инстансы EC2

Принципы ценообразования:

On-Demand - дефолтная опция. Почасовая оплата за время работы инстанса. При прочих равных - самый дорогой вариант, в случае использования 24*7*365.
Reserved Instance - дает большие скидосы (до 72% по сравнению с On-Demand). Фактически - это ценовое соглашение, которое дает право на запуск инстанса оговоренной конфигурации в заданном регионе течение оговоренного срока (1 или три года) по зафиксированной сниженной цене. Как только запускается инстанс подходящий под параметры соглашения - на него действует оговоренная в соглашении цена. Само заключние соглашения предполагает некоторую плату, независимо от того создаются ли подподающие под него инстансы или нет.

Для Reserved Instance доступны две опции:

Standard Reserved Pricing - самые крупные скидки (до 72%) на срок 1 или 3 года. Некоторые параметры инстансов можно менять - AZ, размер, тип сети.
Convertible Reserved Pricing - скидки до 54%, по сравнению с On-Demand. Можно менять семейство машинок, ОС и другие параметры.

Также - для Reserved Instance доступны скидки в зависимости от предоплаты:

All Upfront - оплата за весь срок соглашения вперед.
Partial Upfront - частичная оплата вперед с последующей сниженной почасовой.
No Upfront - без оплаты вперед, с почасовой оплатой, но по-прежнему с некоторыми скидками относительно On-Demand.

Ненужные Reserved-инстансы можно перепродать на Reserved Instance Marketplace (только Standard Reserved). Также, если нужен инстанс на срок меньше стандартный 1 или 3 года - можно подыскать его на маркете. Для продажи инстанса на маркете он должне быть оплачен быть во владении не менее 30 дней.

Spot Instance Pricing

У AWS есть резервные EC2 инстансы, не задействованные в данный момент, которые можно использовать с большой (до 90%) скидкой.
Недостатком использования этих инстансов является то, что они могут быть остановлены в любой момент (по мере роста потребности в On-Demand инстансах).
При остановке инстанс раньше мог быть только удален, но теперь появились и другие опции - выключение или гибернация.
Цены устанавливаются фактически по правилам аукциона. То есть при создании такого инстанса есть текущая цена и задается максимальная цена, которую клиент готов платить за инстанс. Если потреность в инстансах растет и текущие цены превышают заданную максимальную - инстанс останавливается.
По мере падения спотовых цен - при достижении максимальной цены - инстанс снова запускается.
Таким образом - спотовые инстансы могут быть остановлены в трех случаях:

Масксимальная цена, предложенная клиентом, становится ниже актуальной спотовой.
Доступность инстансов - все инстансы могут быть востребованы On-demand.
Ограничения - недоступность инстансов в конкретной AZ.

Пред остановкой, за 2 минуты, Amazon CloudWatch генерирует Event, который может быть обработан Lambda-функцией или Amazon SimpleNotifications (SNS).

Файловые хранилища AWS Elastic File System (EFS)

AWS EFS позволяет создавать файловые хранилища, подключаемые к инстансам по сети. Основные фичи:

Использование в качестве разделяемого централизованного файлохранилища для инстансов EC2 на базе Linux
Доступны для On-Premise серверов через VPN или AWS Direct Connect.
Могут быть увеличены или уменьшены по запросу без потери данных.
Тома EFS привязаны к региону. То есть доступны из любой AZ в регионе.
Не могут быть использованы в качестве загрузочных томов.
Н могут быть использованы инстансами EC2 на базе Windows

Amazon Lightsail

Amazon Lightsail - это полностью сконфигурированные VPS со всем необходимым на борту для какой-то задачи:

WordPress
Drupal
LAMP
etc…

Деплоится легко и быстро, имеет фиксированную стоимость в месяц (от $3.5 за 1vCPU, 512MiB RAM, 20Gb SSD и 1TB трафика в месяц). Также доступны и дополнительные опции - статические IP, DNS, доступ по SSH/RDS и прочее.
Можно сделать снепшот и проапгрейдить Lightsail до стандартного EC2-инстанса.

Amazon Elastic Container Service (ECS)

AWS ECS - сервис запуска Docker-контейнеров в облаке.
Терминология:

ECS Cluster - логическая группа EC2-инстансов на которых крутятся контейнеры. Существует в пределах региона на нескольких AZ.
ECS Container Instances - EC2-инстансы, на которых работает Docker и Tasks (контейнеры).
Task - контейнер.
Task Definition - описание параметров запуска контейнера. Образ, ресурсы, сеть, IAM-роли.
Elastic Container Registry (ECR) - хранилище образов.
ECS Service - задает необходимое количество работающих экземпляров каждой Task и перезапускает их по мере надобности.

Опции запуска ECS

Amazon Fargate - позволет развернуть ECS-инсталляцию без необходимости настройки отдельных EC2-инстансов. То есть просто упаковыевется приложение, указываются необходимые ресурсы (CPU, память и прочее), а дальше Fargate полностью берет на себя все заботы о запуске, масштабировании и дальнейшем управлении инстансами кластера и приложением.
EC2 - Если надо управлять инстансами самостоятельно. Настраивать, апгрейдить и прочее.

Amazon Elastic Kubernetes Service (EKS)

Managed-кластеры k8s.
При создани кластера выбирается тип EC2-инстансов для worker-нод.
После создания кластера нужно установить необходидмые addons - CNI (calico), LoadBalancer Controller для публичных IP-адресов, возможно - Ingress (nginx).

Serverless computing - AWS Lambda

Само понятие Serverless для клиента означает отсутствие необходимости взаимодествия с серверами, и их ОС. Клиент просто предоставляет код для запуска, а AWS обеспечивает и настраивает всю инфраструктуру, необходимую для его исполнения.
AWS Lambda - это Function as a Service.

клиент создает код функции на одном из поддерживаемых языков (Python, Node.js и прочие) и загружает в AWS Lambda
создает триггер, который в ответ на событие или по расписанию будет запускать Lambda-функцию

Например - по событию загрузки изображения на S3 - триггер запускает Lambda-функцию, которая добавляет ватермарк и выгружает в другой бакет.
Или - по расписаню включать и выключать EC2-инстансы.
Оплата AWS Lambda - только за время фактической работы.

AWS Batch

Используется для запуска большого (тысячи) количества вычислительных заданий.
Вся работа по инициализации вычислительных ресурсов (инстансы EC2 или ECS) выполняется автоматически.
Оплаа - за фактически использованные ресурсы.

AWS Outposts

Средства создания гибридных облаков.

Дополнительные опции хранилищ AWS

Amazon FXs for Lustre

Предоставляет доступ к managed файловой системе Lustre, которая способна обеспечить миллионы IOPS и пропускную способность в десятки гигабайт в секунду.
Интегрируется с Amazon S3 для организации долговременного хранения.

Amazon FSx for Windows File Server

Managed файловые шары с поддержкой SMB для Windows-инфрастурктур.
Поддердивает AD и DFS.

Безопасный доступ к VPC - Bastion Hosts и Session Manager

Для уменьшения поверхности атаки применяются Bastion Hosts и Session Manager.

Bastion Hosts - это специально настроенные EC2-инстансы, которые используются исключительно для доступа к инстансам в приватных сетях. Доступ к самим jump-хостам может ограничиваться по диапазону адресов или с помощью VPN.
Session Manager - это консоль в браузере, для работы которой не надо открывать порты на Security Groups и управлять SSH-ключами. Действия администраторов записываются для дальнейшего аудита.

8. Сервисы AWS Databases

Amazon дает возможность создавать managed-базы данных. традиционные реляционные (RDS) или неструктуриованные NoSQL.

Amazon RDS

Поддерживаются шесть движков БД:

MySQL
PostgreSQL
MariaDB
Microsoft SQL Server
Oracle
Amazon Aurora

При создании инстанса:

выбирается тип EC2-инстансов кластера - это влияет на производительность
создается кластер (одно- или многонодовый), в котором можно создать одну или несколько БД

Инстансы могут быть:

Стандартные (m-класса). Подходят для большинства нагрузок. От 2 до 96 CPU, до 384 GiB RAM
Memory-optimized (r и x-классы) - Подходят для нагруженных приложений. От 4 до 128 CPU. До 3904 GiB RAM.
Burstable (t-классы) - Для непродукционных БД. Обеспечивают базовый уровень производительности с возможностью кратковременных всплесков нагрузки. От 1 до 8 CPU, до 32 GiB RAM

EBS-тома могут быть:

General Purpose SSD - подходит для большинства БД. От 20GiB до 64TiB (до 16TiB для MS SQL). IOPS зависят от объема. Минимум - 100 IOPS, дальше - по 3 IOPS на GiB. То есть 60GiB покажут 180 IOPS. Тома меньше 1TiB кратковременно дают повышенную производительность (burst) при необходимости.
Provisioned IOPS SSD - Рекомендованный тип. Объем - до 64 TiB. Необходимый уровень IOPS задается вручную. Bust - нету.
Magnetic - легаси. Не рекомендовано. До 1000 IOPS и до 3TiB объем.

Можно апгрейдить тип хранилища, но это может потребовать кратковременной остановки БД.

Особенности деплоя Amazon RDS

Инстанс Amazon RDS существует в рамках региона.
Деплоится в существующий VPC, в заданную подсеть в заданной AZ.
Кластеры RDS являются Active-Passive. То есть Master-нода, которая пишет данные - всегда одна.
Доступ к инстансу RDS регулируется с помощью Security Groups и NACLs

Сценарии поключения к инстансу Amazon RDS могут включать:

Подключение в рамках VPC. Настраивается Security Group на порт инстанса.
Подключене из другого VPC (другой регион, другой аккаунт). Настраивается VPC Peering (VPC Transit Gateway) и правила Secuity Groups
Подключение через интернет. Инстанс RDS размещается в публичной подсети. Небезопасно.
Из частной on-premise сети. Через VPN или Direct Connect

Резервирование и восстановление Amazon RDS

Для выбора оптимальной стратегии резервирования важно определить два параметра:

RTO (Recovery Time Objective) - допустимое время восстановления после отказа.
RPO (Recovery Point Objective) - допустимые потери данных в результате сбоя.

Например - нужно восстановиться за 1 час (RTO) и потерять данные записанные в БД не более чем за 2 часа (RPO).
Логично, что чтобы реализовать RPO 2 часа нужно делать бекапы каждый 2 часа.

Реализация отказоустойчивых БД - Multi AZ

Классический кластер Active-Passive:

В двух AZ расположены master-нода и standby-реплика. Репликация - синхронная.
При выходе из строя master-ноды - происходит автоматический переход роли master к реплике. Во время перехода - возможно отсутствие доступа к БД (до двух минут).
Старый master уничтожается, вместо него поднимается новая нода - копия реплики. Запускается репликация.

Таким образом можно снизить RTO и RPO практически до нескольких минут.
Переключение между master и standby нодами может быть полезно и в случаях необходимости технических работ на master-ноде (апгрейд, изменение конфигурации).

Автоматическое резервное копирование

Amazon RDS выполняет автоматическое регулярное резервное копирование через заданные интервалы времени в заданные для этого “окна”.
Механизм создания резервных копий - снепшоты. Первый - полный, последующие - инкрементные.
Retention - определяет количество хранимых копий. от 1 до 35 дней. 0 - значит бекапы выключены.
AWS RDS чрез заданный интервал (обычно 5 минут) сохраняет на S3 логи транзакций. Таким образом - с помщью бекапа и логов транзакций можно восстановить состояние БД на любой момент (в пределах retention) с точностью до заданного интервала (LastRestorableTime)

Резервное копирование вручную

Полезно перед масштабными изменениями в БД.

Межрегиональное резервное копирование

Можно включить репликацию бекапов в другой регион, на случай серьезного дизастера.

Кратковременный отказ в обслуживаннии при начале резервного копирования

При создании снепшота БД в конфигурации, когда есть только одна master-нода, может происходить “замирание” ввода-вывода на несколько секунд.
Это стоит учитывать при выборе “окна” для создания резервных копий.
В конфигурации Multi-AZ такого не происходит, поскольку снепшот для бекапа снимается со standby-ноды

Горизонтальное AWS RDS масштабирование с репликами "только для чтения"

В кластере Active-Passive запросы обрабатывает только master-нода. Обратиться к standby-ноде невозможно - она только реплицирует данные и ждет дизастера.
Если необходимо - для повышения производительности можно настроить ноды-реплики “только для чтения”.

Они пригодны для приложений, которые не пишут в БД. Например - аналитика.
Репликация - Ассинхронная. То есть возможны задержки в обновлении данных, относительно боевого мастера.
Возможна репликация в другие регионы.
Для каждого инстанса AWS RDS можно настроить до 5 read-only реплик
Read-only реплику при необходимости можно промотировать до полноценной master-ноды.

Amazon Aurora

Amazon Aurora - проприетарная разработка Amazon.
Эта БД совместима с MySQL и PostgreSQL, но в пять раз быстрее, чем MySQL и в три раза быстрее, чем PostgreSQL
отказоустойчивая конфигурация - минимум три ноды (в разных AZ).
Объемы БД - до 128TiB
Репликация - до 15 read-only реплик.
Деплоится в виде DB-кластеров, в котором используются два типа инстансов, а также общее хранилище - cluster volume (размещенный на нескольких storage-nodes в нескольких AZ):

Primary DB instance - операции чтения-записи. Только этот инстанс может писать в cluster volume. Может быть только одна.
Aurora replica - только для чтения, до 15 штук.

Доступна как в классическом серверном варианте, так и serverless

Amazon Aurora Serverless

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

Amazon DynamoDB (NoSQL)

Fully-Managed бессерверная NoSQL БД.
Существует в рамках региона.
Динамически подстраивается под нагрузку.
Расчитано на миллионы записей и тысячи запросов в секунду.

Терминология DynamoDB

Таблицы (Tables) - Подобны таблицам в SQL-базах. Также есть Primary Key, который должне быть уникальным в пределах таблицы.
Items - аналогичны записям в SQL. В таблице может быть один или больше Items, каждый состоит из какого-то количества аттрибутов (attributes). Размер Item - до 400KB.
Аттрибуты (attributes) - Пары ключ-значение (key-value). Ключи - подобны названиям колонок в SQL.

В отличие от SQL - не нужно заранее определять схему и типы данных в колонках.
Ключи (за исключением Primary) можно добавлять/удалять в любой момент.
Значения ключей могут иметь следующие типы:

Scalar - Просто значение. Строка, число, двоичная строка, булево значение или null.
Set - Набор скалярных значений. Наборы строк, бинарных строк, набор чисел.
Document - JSON-структура, которая может включать вложенные аттрибуты. Документы могут быть двух типов: JSON List и JSON Map.

Определение требований к инстансу DynamoDB

При создании инстанса нужно указать параметры планируемой нагрузки:

RCU (read capacity units) - единицы производительности на чтение
WCU (write capacity units) - единицы производительности на запись

Дальше - в зависимости от значений Amazon определит необходимые параметры инстанса.
Доступны две опции:

On-Demand - динамическое выделение ресурсов в зависимости от нагрузки
Provisioned - для предсказуемых нагрузок. Задается предполагаемое количество операций чтения и записи в секунду. Всегда можно включить auto-scaling, для адаптации к текущей нагрузке.

Amazon RedShift - Data Warehousing

Предназначен для извлечения данных из других (реляционных) БД и построения аналитики по созданным датасетам - OLAP operations (OnLine Analitical Processing).
Клиентам Amazon такде доступно BI-приложение (business intelligence).
Является колоночной (column storage) БД (в противовес реляционным, где каждая запись - ряд). Это позволяет при чтении снизить количество операций IO в три раза, по сравнению с реляционными БД.
Архитектура - кластер:

Leader node - выделенная нода, через которую происходит взаимодйствие с БД RedShift. Компилирует код запросов и распределяет задания по вычислительным нодам.
Compute node - до 128 нод в кластере. Получают задачи, отправляют назад результаты. Бывают трех типов:
- Dense compute nodes - До 326TB данных на HDD
- Dense storage nodes - до 2PB на SSD
- RA3 instances - новое поколение на базе Nitro. Используют managed storage (в отличие от предыдущих). Хранилища отделены от вычислителей, в свою очередь хранение горячих данных - на локальных SSD, холодных - на S3. Поата - только за фактически использованный объем.

RedShift Spectrum

Сервис реализующий SQL запросы к данным, хранимым в AWS S3.
Например - у вас много нечасто нужных данных в S3.
Вместо того, чобы импортировать их в дорогостоящие инстансы RedShift и затем обращаться к ним - можно сразу обращаться к данным в S3.

Amazon Elasticache

сервис кеширования горячих данных в памяти.
Доступны два варианта:

Amazon Elasticache for Redis - кластер из одной ил нескольких кеш-нод. Для кеширования сложных объектов. Умеет Multi-AZ, шифрование, отказоустойчивость
Amazon Elasticache for Memcached - Для кеширования простых объктов (типов данных).

Amazon Neptune

Fully managed БД Графов
Хранит данные в виде нод, их аттрибутов и связей между ними.
Поддерживает многие широко применяемые модели:

Property Graph
W3C's RDF

И языки:

Apache TinkerPro
Gremlin
SPARQL

Применяется при анализе “больших данных”:

фрод детекш
графы знаний
исследование лекарств
сетевая безопасность

Amazon Quantum Ledger Database (QLDB)

Fully Managed Blockhain от Amazon.

Неизменный и прозрачный. Непрерывный журнал транзакций.
Криптографически валидируемый.
Простой в использовании. Язык PartiQL
Серверлесс - необхоимые для текущей нагрузки мощности выделяются автоматически.

Amazon Database Migration Service (DMS)

Сервис для миграции on-premise БД в облако. Поддерживаются как гомогенные миграции - MySQL → MySQL, так и гетерогенные - Oracle → MS SQL или MS SQL → Amazon Aurora.
Во время миграции БД остается работоспособной, уменьшая даунтайм.
Может использоваться для непрерывной репликации on-premise БД в облако для отказоустойчивости.

9. Отказоустойчивость и эластичность AWS - (HA and Elasticity)

Вертикальная и горизонтальная масштабируемость
Модель Open System Interconnection (OSI)
Балансировка трафика с помощью Amazon Elastic Load Balancing (ELB)
Реализация эластичности с помощью AWS Auto Scaling
Проектирование мультирегиональных отказоустойчивых решений.

Вертикальная и горизонтальная масштабируемость

Вертикальная - апгредим ресурсы инстансов.
Горизонтальная - увеличиваем количество инстансов

Вертикальаня масштабируемость

требует остановки инстанса
может занимать много (часы) времени
не обеспечвает отказоустойчивости

Горизонтальная масштабируемость

повышает отказоустойчивость
может быть реализована автоматически

Модель OSI

Ну что про нее сказать - она самая!!!

Распределение (балансировка) трафика с помощью Amazon Elastic Load Balancer ELB

ELB - работает в пределах региона и не может балансировать между регионами.
В качестве бекендов могут выступать:

инстансы EC2
IP-адреса
контейнеры
Lambda-функции
и прочие сущности…

Общие правила использования ELB

Любой ELB рекомендуется размещать более чем в одной AZ. В таком случае - в каждой AZ будет нода балансировщика (load balancer node), которая будет распределять трафик по инстансам в этой зоне.
Если есть ELB, то размещать инстансы в публичных сетях нет необходимости. Клиенты ходят только через ELB.

Балансировщики ELB бывают двух видов:

Internet-facing load balancer - доступен в internet, имеет DNS-имя.
Internal load balancer - балансируют ресурсы внутри приватных сетей VPC.

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

Application Load Balancer (ALB)
Network Load Balancer (NLB)
Gateway Load Balancer (GWLB)
Classic Load Balancer (CLB)

Application Load Balancer (ALB)

Это L7-балансировщик (application layer).
Работает с протоколами HTTP и HTTPS.
Поддерживает:

Path-based роутинг - для распределения запросов в зависимости от URI в запросе
Host-Based роутинг - для распределения в зависимости от содержимого заголовка HOST в запросе
Множество приложений на одном EC2 инстансе
В качестве бекэндов могут выступать Lambda-функции и контейнеры и многое другое

Состоит из:

listener - сервис, который на иснове правил респределяет запросы. Правил может быть одно или более.
target groups - группы (одна или более) инстансов (или контейнеров, Lambda-функцй и т.д.), на которые listener направляет запросы.

Health Checks

Поддердивается проверка состояния бекэнд-инстнсов в target groups
Неработоспособные инстансы удаляютяс из баланссировки до момента восстановления

ALB и Web Application Firewall (WAF)

ALB интегрируется с WAF, который фильтрует поступающие запросы для защиты от типичных атак:

SQL-инъекции
cross-site-scripting (XSS)
и других

NLB

Балансировщик L4 - балансирует как TCP, так и UDP протоколы.
Свойства:

Обеспечивает очень низкие задержки.
Интересен тем, что может сохранять IP-адрес клиента во входящих запросах.
Поддерживает статические и elastic IP-адреса (по одному на AZ).
В качестве target-ов выступают IP-адреса, а значит можно балансировать и ресурсы вне VPC, например - on-premise
Одн инстанс NLB позволяет балансировать различные ресурсы/протоколы, принимая подключения на разных портах.
Поддерживаются приложения в контейнерах (Amazon ECS)

GWLB - Amazon GateWay Load Balancer

Amazon GWLB выступает в качестве единой точки входя для траффика, который должен быть проанализирован различными внешними инструментами (файерволы, IDSes/IPSec - intrusion detection/prevention). Инструменты доступны на Amazon Marketplace в виде virtual appliances.

Работает на третьем (Layer 3) модели OSI
С IPSec/IDSec-приложениями взаимодействует по протоколу GENEVE (Generic Network Virtualization Encapsulation) на порту 6081
Является statefull-сервисом, то есть трафик ходит как к IPSec/IDSec-приложениям, так и от них.

CLB - Amazon Classic Load Balancer

CLB - первая реализация балансировщика в AWS.

Не подходит для продукционных задач, но пригоден для тестирования, либо - для приложений, использующих EC2-Classic network mode
Работает на 4 и 7-уровнях OSI
Не предоставляет всех функций ALB, либо производительностb NLB.
Балансирует трафик по EC2-нодам в предалх региона (на одну AZ либо на многие)

Эластичность и Amazon Auto Scaling

Эластичность - предполагает автоматическое масштабирование облачных ресурсов по мере роста/уменьшения нагрузки.
Масштабирование происходит в ответ на события, например - это превышение/уменьшение значений каких-либо метрик (например - загрузка CPU), либо - таймер.
Auto Scaling - это региональный сервис, который работает с метриками и EC2-инстансами в пределах региона AWS.

Параметры Auto Scaling

Для реализации автоматического масштабирования настраиваются Auto Scaling Groups - они описывают коллекцию (fleet) EC2-инстансов и параметров масштабирования:

Минимальное число EC2-инстансов в группе.
Желательное (desired) число инстансов в группе. Сервис будет всегда стремиться автоматически поддерживать это число EC2-инстансов.
Максимальное число EC2-инстансов в группе. Нужно для избежания ненужных расходов, например - в случае бага в ПО, который приводит к бесполезной высокой нагрузке на CPU.

Сервис Auto Scaling выполняет автоматические health-чеки (выполлянемые через ELB или самим AutoScale) и реагирует на их результаты действиями, прописанными в политиках масштабирования.

Шаблоны конфигураций

Для настройки AWS Auto Scaling создаются либо Launch Template, либо - Launch Configuration - спецификации EC2-инстансов:

Образ Amazon Machine Image (AMI)
тип инстанса (конфиг железа)
SSH-ключи для доступа к инстансу
Спецификации Block Storage
Скрипты для провижининга EC2-инстансов (bootstrapping). Это скрипты на Bash либо PowerShell

Чем отличаются Launch Configuration и Launch Template:

Launch Configuration - это первая реализация шаблонов с параметрами инстансов. В настоящий момент не рекомендованы к использованию. Шаблон может быть использован в нескольких AutoScale Groups, но в пределах одной AutoScale Group может испрльзоваться только одна Launch Configuration. После создания Launch Configuration изменить ее параметры нельзя, а можно только пересоздать её.
Launch Template - актуальная реализация шиблонов для AWS Auto Scale. Аналогичен Launch Configuration, однако может иметь несколько различных версий, содержать базовый шаблон и несколько дополнительных на разные случаи, запускать как On-Demand, так и спотовые инстансы, запускать различные конфигурации инстансов. Также - поддерживает новые фичи типа ESB volumes gp3 и io2, ESB volume tagging, elastic inference, Dedicated Hosts.

Политики Масштабирования

Масштабирование триггерится в ответ на события. Это все настраивается в политиках масштабирования (scale policy):

Поддержание заданного числа инстансов. Вышедшие из строя инстансы удаляются и заменяются на свежие.
Масштабирование вручную
Масштабирование по расписанию.
Динамическое масштабирование (по требованию). В ответ на значения метрик.

В свою очередь динамическое масштабирование может быть таким:

Слежение за целевыми показателями - Target Tracking Scale policy. Пытается поддерживать значение заданной метрики на заданном уровне.
Пошаговое (не плавное) масштабирование (Step scaling) - количество подключаемых дополнительно EC2-инстансов зависит от фактического превышения значения метрики над заданным. Чем больше превышение, тем больше шаг масштабирования.
Простое масштабирование (simple scaling) - масштабируемся до заданного размера в зависимости от значения одной метрики.
Масштабирование с предсказанием (Predictive Scaling) - масштабирование на основании предсказания уровня нагрузки, запланированных (scheduled) действий, превышения максимальной емкости - когда можно настроить автоматичсекое увеличение максимального разрешенного количества инстансов, в зависимости от условий.

Проектирование мульти-региональных отказоустойчивых решений AWS

Эффективные механизмы обеспечения высокодоступных решений - Amazon ELB и Amazon Auto Scaling - работают только в пределах региона AWS.
Однако, обеспечить высокую доступность на случай выхода из строя целого региона можно с помощью Amazon Route 53 и Amazon Cloud Front.

Amazon Route 53 позволяет настроить мультирегиональную active/passive-конфигурацию с помощью failover-роутинга
В запасном регионе может работать минимум EC2-инстансов, обеспечивая подхват нагрузки, если health-чеки основного региона на Amazon Route 53 покажут, что он сдох. А также - политики AWS Auto Scale, которые промасштабируют инфраструктуру при возрастании нагрузки.

10. Сервисы AWS для интеграции приложений

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

app-to-app (A2A) messaging - передачи сообщений между приложениями
app-to-person (A2P) messaging - передачи сообщений от приложений к пользователям
проектирования event-driven приложений
связи сервисов в бессерверных инфраструктурах

Сервисы AWS для интеграции приложений включают в себя:

Amazon Simple Notification Services (SNS) - сервис простых push-сообщений сервисам или непосредственно пользователям
Amazon Simple Queue Services (SQS) и Amazon MQ - сервисы очередей сообщений
Amazon EventBridge - сервис для построения event-driven приложений
Amazon Step-Functions и Amazon Simple Workflow Service (SWF) - для организации приложений на основе бессерверной инфраструктуры

Amazon Simple Notification Services (SNS)

Это сервис для push-сообщений сервисам или непосредственно пользователям.
Работает по принципу издатель/подписчик (publisher/subscriber). Каждый издатель может отправить сообщение одному или нескольким подписчикам.
Пример использования - необходимо получать оповещения о загрузке объектов в S3.

настраиваются оповещения S3 event notifications на событие s3:ObjectCreated:*
Создается SNS topic, в который отправляются эти оповещения
На даный топик создается подписка, с e-mail адресом

В результате - при заливке объектов в S3 на почту приходит сообщение. Это A2P.
В качестве подписчика пожет выступать Lambda-функция, которая может что-то делать с загруженным объектом. Это A2A.

Amazon SNS Endpoints

Для получения сообщений подписчики должны предоставлять один из заданных типов эндпоинтов.
A2A Endpoints:

Amazon SQS - сообщение в очередь сообщений.
HTTP(S) - сообщение в какой-то REST API
AWS Lambda - сообщение Lamda-функции
Amazon Kinesis Data Firehose - сообщения могут быть переданы в S3, Elasticsearch, RedShift или куда-то еще

A2P Endpoints:

e-mail
SMS на мобилку
мобильные push-сообщения

Amazon SNS Topics

Чтобы сообщение было доставлено - нужно создать topic, куда издатель (publisher) его отправит и на который подпишутся подписчики (subscribers).
Для издателей настраиваются политики доступа к топикам - то есть в примере в S3 - бакету нужно дать права с помощью IAM-политики на публикацию сообщений в топике. Политика назначается на топик.
Правила наименования топиков:

до 256 символов
могут содержать дефисы и подчеркивания

ARN выглядит так: arn:aws:sns:eu-west-2:123456789789:new-object-upload-alert

Типы топиков SNS

Standard - дефолтный тип. Используется, когда порядок доставки сообщений и возможные дубли - не важны. Поддерживаются все протоколы.
FIFO - Обеспечивают строгий порядок доставки сообщений без дублей. Поддерживается только эндпоинтами Amazon SQS.

Amazon SNS Fanout

Amazon SNS Fanout - это механизм репликации сообщений множеству подписчиков.
Работает - параллельно и ассинхронно.
Реализуется с помощью Amazon Kinesis Data Firehose
Пример - нужно чтобы сообщения от Lambda-функции, которая обрабатывает заказ билета передавались Lambda-функции, которая обрабатывает платеж и далее - в Amazon Redshift для истории.

Lambda-функция продажи билета отправляет сообщение в SNS topic.
Сообщение реплицируется в две точки - очередь SNS и Amazon Kinesis Data Firehose.
Из очереди сообщений - его забирает Labmda-функция обработки платежей.
Amazon Kinesis Data Firehose передает сообщение в кластер RedShift. Путь такой - сначала данные копируются в бакет S3, а затем - выполняется команда Amazon RedShift COPY

Стоимость использования Amazon SNS

Платим только за сообщения.

Standard topics - платим за вызовы API в месяц. Например - мобильные push-сообщения - $0.5 за миллион сообщений в месяц. Объем сообщений - до 256KB, для мобильных SMS - 64KB.
FIFO topics - платим за всё - за опубликованные сообщения, за доставленные сообщения и за объем переданных данных.

Amazon SQS и Amazon MQ для реализации микросервисной архитектуры

Брокеры очередей сообщений Amazon SQS и Amazon MQ - позволяют перейти от монолитных приложений к микросервисам. Amazon SQS и Amazon MQ представляют дополнительный высоконадежный слой взаимодействия между элементами приложений, что в итоге позволяет:

посылать и обрабатывать сообщения в/из очереди независимо
ассинхронно
масштабировать разные элементы приложения независимо

Пример сценария, использующего Amazon SQS - приложение конвертирующее видео-файлы в разные разрешения и форматы:

Пользователи заливают файлики на web-серврах, количество которых автоматичсеки масштабируется в зависимости от нагрузки
Файлы попадают в бакет S3
При появлении нового файла сообщение с помощью Amazon SNS отправляется в несколько очередей Amazon SQS в режиме Fanout
Очереди SQS хранят сообщения до момента, когда они будут прочитаны одним из серверов приложений
Сервера приложений читают сообщения, в которых указано какой файл и в какой формат нужно сконвертировать
Файлики конвертируются и складываются куда надо

В то время,как Amazon SNS является источником push-событий, Amazon SQS - это pull-based платформа, где чтение сообщений инициируется серверами приложений.
Сообщения в amazon SQS могут храниться некоторое время (дефолт 4 дня, до 14 дней).

Типы очередей Amazon SQS

Standard queue - поддерживают практически неограниченное количество API-запросов в секунду (SendMessage, ReceiveMessage, DeleteMessage) и предназначены для сообщений, которые должны быть доставлены хотя бы один раз. Не исключены дубли. Порядок доставки сообщений - не гарантируется. Глубина очереди не может превышать 120 000 записей.
FIFO queue - исключают дубли и порядок доставки. Скорость - до 300 сообщений в секунду. Более высокие скорости достиживмы в пакетом режиме - до 3000 сообщзщений в секунду (пачками по 10 сообщений).

Шифрование сообщений

Сообщения в Amazon SQS могут быть зашифрованы с помощью ключей Amazon KMS (Key management Service).

Оплата SQS

Платим только за сообщения и взаимодействия с S3 и KMS.

Amazon MQ

RabbitMQ-совместимый брокер сообщений.
Ориентирован на клиентов, мигрирующих в облако. Не имеет других преимуществ перед Amazon SNS и Amazon SQS, которые предпочтительны для новых приложений.
Поддерживает API JMS и протоколы:

AMPQ 0-9-1
AMPQ 1.0
MQTT
OpenWire
STOMP

Проектирование event-driven приложений на базе AWS EventBridge

Amazon EventBridge - это шина событий, для обработки сообщений поступающих в реальном времени и реакции на них.
Amazon EventBridge - это новая версия инструмента, ранее называвшегося Amazon CloudWatch Events.
В качестве обработчиков могут выступать:

AWS Lambda
Kinesis
HTTP(S) эндпоинты
шины событий в других аккаунтах
SNS топики
таски ECS
SQS-очереди

События генерируются в ответ на изменение состояния ресурса (например - EC2-инстанса, события AutoScale).
Amazon EventBridge путем создания правил, описывающих шаблоны событий и таргеты, куда будет отправлено оповещение.
Amazon EventBridge может запускать действия по таймеру.
В отличие от Amazon CloudWatch Events, который имел только одну дефолтную шину событий (для событий AWS и кастомных), Amazon EventBridge позволяет создавать кастомные шины, который могут быть выделены для обработки катомных событий от приложений. Также Amazon EventBridge поддерживает интеграцию с внешними приложениямитакими как ZenDesk, PagerDuty, Datadog.
Терминология Amazon EventBridge:

События (Events) - изменения состояния ресурсов (приложений, AWS-ресурсов, внешних приложений).
Правила (Rules) - шаблоны событий, которые подлежат обработке. Содержат также шаблоны JSON-данных, отправляемых в обработчик (target)
Обработчики (targets) - Реагируют на события и выполняют действия.
Шины событий (Event Buses) - они (дефолтная и кастомные) получают события от источников и содержат правила и обработчики.

Amazon Step Functions и Amazon SWF

Это еще два сервиса, реализующие взаимодействие между компонентами приложений, позволяющие создавать бессерверные решения.

Amazon Step Functions

Amazon Step Functions - связывают различные элементарные обработчики данных (Lambda-функции, контейнеры ECS) в единый WorkFlow.
Amazon Step Functions - позволяют описывать и визуализировать workflow прикладных задач в виде отдельных блоков - конечных автоматов, называемых states, каждый из которых на входе получает даные, в том числе и интерактивно от пользователя, а затем принимает решение на их основе и передаёт дальше по цепочке следующему state или внешнему обработчику типа Lambda-функции.
State бывают следующих видов:

Success or Fail state - остановка/продолжение обработки в зависимости от входных данных
Wait State - ожидание в течение заданного времени
Parallel State - создание параллельных ветвей исполнения
Map State - осуществляется обработка списка входящих параметров
Choise state - выбор ветки исполнения на основе входящих данных
Task state - выполнение обработки анных с помощью других сервисов AWS, например - Lambda-функций

Amazon Step Functions используют JSON-объекты Amazon State Language (ASL) для описания конечных автоматов.

Типы Workflow

Standard workflow - предполагает однократное исполнение, подходит для интерактивных задач, может длиться до 1 года. Оплата - за каждый переход от одного state к следующему. Предоставляют доступ к истории исполнения и визуальный отладчик.
Express Workflow - Подходят для автоматических задач. Исполнение в течение максимум 5 минут. Оплата - за количество и длительность исполнения. История исполнений передается в Amazon CloudWatch

Amazon Simple Workflow Service (SWF)

Amazon SWF - еще один, наряду с Amazon Step Functions сервис компоновки сложных задач из элементарных обработчиков (workers), работащих на инстансах EC2 или on-premise.
Основное отличие Amazon SWF от Amazon Step Functions - это способ описания workflow.

Amazon Step Functions - это простое декларативное JSON-описание взаимодействия между обработчиками внутри AWS.
Amazon SWF - предполагает написание программы на любом языке, которая получит состояние предыдущего обработчика и передаст следующему. Позволяет использовать внешние, сервисы.

11. Сервисы AWS для анализа информации

Amazon Kinesis - стриминг данных

Amazon Kinesis - fully-managed сервис для немедленной обработки данных по мере их поступления.
Включает в себя 4 основых сервиса:

Amazon Kinesis Data Firehose
Amazon Kinesis Data Streams
Amazon Kinesis Data Analytics
Amazon Kinesis Video Streams

Amazon Kinesis Data Firehose

Amazon Kinesis Data Firehose - по функционалу напоминает Logstash от Elastic, но не обеспечивает кеширования.
Amazon Kinesis Data Firehose - сервис для приема данных и передачи их в:

Сервисы Amazon - S3, RedShift, Elasticsearch
Внешние сервисы - DataDog, New Relic, MongoDB, Splunk

Amazon Kinesis Data Firehose позволяет:

выполнять пакетные операции над поступающими данными - сжатие, преобразование, шифрование. Это снижает общую стоимость обработки и хранения.
преобразовывать в открытые форматы - Apache Parquet, Apache ORC

Оплата - только за количество обработанных данных. Без резервирования и предоплат.

Amazon Kinesis Data Streams

Amazon Kinesis Data Streams - real-time сервис для получения и стриминга данных в кастомные приложения (Lambda-функции или AWS S3). В отличие от Amazon Kinesis Data Firehose, который ориентирован на стриминг данных в хранилища.
Свойства Amazon Kinesis Data Streams:

Типичное время обработки сообщения - 70ms
высокая доступность - собираемые данные реплицируются в три AZ.
в отличие от Amazon Kinesis Data Firehose, Kinesis Data Streams может хранить собранные данные от дефолтных 24 часов, до 7 (retention) или даже 365 (long term retention) дней.
предназначен для - real-time дашбордов, детектинга аномалий, анализа цен в реальном времени
транзакции обрабатываются в шардами, количество которых опредеяет доступную скорость обработки. Производительность каждой шарды - на чтение до 5 транзакций, до 2 MB данных на шарду в секунду. На запись - до 1000 сообщений, до 1MB данных в секунду.
Оплата - почасовая за зарезервированные шарды (пропускную способность), независимо от того, используются ли все зарезервированные шарды или нет

На первый взгляд может показаться, что Amazon SQS и Kinesis Data Streams абсолютно одинаковые, однако это не так. Amazon SQS - это слой взаимодействия между компонентами приложений, очередь сообщений, с издателями и подписчиками. А Kinesis Data Streams - это просто стриминг сообщений, аналог logstash с резервируемой и гарантированной пропускной способностью, а также хранением при необходимости.

Amazon Kinesis Data Analytics

Сервис построения приложений для анализа данных, собираемых Amazon Kinesis Data Streams или Managed Streaming for Kafka (MSK).
Позволяет использовать стандартные способы обращения к БД - с помощью языков Java, Python, Scala, SQL, а также отрытого фреймворка дял потокой обработки данных - Apache Flink.
Для разработки приложений потоковой обработки доступна среда Kinesis Data Analytics Studio.

Amazon Kinesis Video Streams

Amazon Kinesis Video Streams - сервис хранения, каталогизации, воспроизведения и анализа видеопотоков.
В качестве хранилища использует S3.
Amazon Rekognition - сервис анализа видеопотоков для выявления объектов, лиц, сцен, текста, изображений.
Например - можно организовать стриминг с камер возле дверей домов, распознавать людей, которые стучатся в дверь и уведомлять пользователей.

Обработка данных из Amazon S3 с помощью Amazon Athena

Часто, данные выгружаются на S3 потому что они нужны нечасто и держать их в одной из баз Amazon RDS или NoSQL нецелесообранзно.
Для быстрого и удобного доступа к таким данным используется fully-mnaged бессерверный сервис Amazon Athena, который позволяет выполнять SQL-запросы к данным хранящимся на S3.
Формат хранения данны на S3 может быть как структурированным, так и неструктурированным - CSV, JSON, ORC, Apache Parquet.
Кроме того, Amazon Athena предоставляет драйвер JDBC для взаимодейтсия с популярными BI-приложениями.
Процесс доступа предполагает создание (автоматически или вручную) базы данных и таблиц с даными на основе метаданных, которые указывают Amazon Athena формат данных на S3.
Результаты запросов могут быть выгружены на S3.

Amazon Elasticsearch (AWS OpenSearch)

OpenSearch - это Managed-сервис от Amazon реализующий все прелести Elasticsearch. Используется свой дистрибутив - OpenDistro
Доступны Kibana и Logstash.
OpenSearch может получать данные из Amazon Kinesis Data Firehose, Amazon CloudWatch Logs, и AWS IoT

Amazon Glue и Amazon QuickSight

Сервисы для объединения данных из различных источников - БД, стримингов, S3 и прочих.

Amazon Glue

Amazon Glue - это serverless managed ETL-сервис (Extract, Transform, Load).
Он позволяет извлекать, преобразовывать и загружать данные из обних хранилищ в другие, тем самым объединяя и обогащая данные.
Amazon Glue содержит Data Catalog - центральное хранилище метаданных, которое хранит сведения о данных (например - опредения таблиц).
Для обнаружения данных и сбора сведений об их структуре и типах используется crawler.
Crawler сканирует источники, обнаруживает данные и сохраняет информацию о них в Data Catalog.
Затем - собранные метаданные используются для построения ETL-скриптов, преобразующих данные в нужные форматы.
Для работы с Amazon Glue используется AWS Glue console которая может:

Создавать определения Glue-объектов (jobs, crawlers, tables и прочих)
Планировать запуски crawler'ов
Определять тригеры для запуска job'ов
Искать и фильровать объекты в Glue
Редактировать ETL-скрипты

Биллинг - на основании ресурсов и времени их использования, почасовой (с посекундным разрешением), а также на основании количества использованного места для хранения метаданных в AWS Glue Data Catalog.

Amazon QuickSight

Fully Managed, serverless BI-сервис для формирования и публикации интерактивных BI-дашбордов.
Может использовать данные из сервисов AWS, БД on-premises, из сервисов SaaS и B2B-данные.
Дашборды могут быть использоваться как на PC, так и на мобильных девайсах.
QuickSight интегрируется с ML-сервисами (ML Insights) для глубокого анализа, выявления отклонений и аномалий в данных.
Также - итоги анализа могут быть сформулированы обобщены в виде описания на естественном языке.
Биллинг - по числу пользователей этих дашбордов.

Другие сервисы анализа данных от Amazon

Elastic Map Reduce (EMR)

AWS EMR - это managed Hadoop framework.
Может использоватьс с инструментами Apache Spark, Apache Hive, Apache HBase, Apache Flink, Apache Hudi и Presto.
Включает в себя свою IDE - EMR Studio., которая поддерживает разработку на R, Python, Scala и PySpark.
Рабочие нагрузки можно запускать на EC2-инстансах и в кластерах k8s - AWS EKS, а также on-premises с помощью AWS Outpost.
Биллинг - за каждый инстанс, посекундный с минимальным интервалом использования 1 минута.

AWS Data Pipeline

web-сервис для автоматизации переноса и преобразования данных из различных источников (on-premise и других) в сервисы AWS (S3, RDS, DynamoDB, EMR).
Например - настроить автоматическую архивацию логов web-сервера в S3 и затем - запускать EMR-job для анализа и генерации репортов.

AWS CloudSearch

Managed-сервис для организации поиска в web-приложениях.
Поддерживает 34 языка и разные сложные поисковые запросы для поиска по сайтам.

12. Автоматизация и развертывание приложений в AWS

В даном разделе рассматриваются:

Деплоймент приложений с помощью Amazon Elastic Beanstalk
Infratructure As A code с помощью Amazon CloudFormation
Оркестрация конфигураций с помощью Chef и Puppet на базе AWS OpsWorks
Автоматизация с помощью AWS Lambda

Деплоймент приложений с помощью Amazon Elastic Beanstalk

Сервис Amazon Elastic Beanstalk позволяет полностью автоматически выполнять:

создание и конфигурацию инфраструктуры для приложений
Масшатбирование
настройку балансировщиков
настройку мониторинга

Подерживаются приложения на следующих языках:

Go
Java
.NET
Node.js
PHP
Python
и некоторые другие

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

Базовые концепции Elastic Beanstalk

Environment - это все инфраструктурные компоненты, которые создает Elastic Beanstalk во время деплоймента. Каждый environment может исполнять только одну версию приложения, а для работы нескольких версий одновременно - можно создать несколько environment. Параметры каждого можно менять, например - для апгрейда приложения.
Environment tier - тип окружения, который определяется свойствами публикуемого приложения. Их два - web server environment и worker environment

Web Server environment tier

Позволяет автоматизировать публикацию web-фронтендов.
Настраивает ec2-инстансы в нейскольких AZ, автоскейлинг для них, балансировщики нагрузки, а также - весь стек, необходимый для работы приложения.
Например публикация .NET приложения для Windows подразумевает настройку Windows-based инстансов EC2 и заданую версию IIS.
Также - приложение автоматически публикуется, для чего создается DNS-запись вида app-name.region.elasticbeanstalk.com, на которую можно ссылаться с помощью CNAME-записей.
На созданных EC2-инстансах деплоится host manager (HM), который:

Деплоит приложение
Собирает метрики с серверов
Генерирует события
Мониторит лог-файлы приложения на предмет критических ошибок
Мониторит состояние сервера приложений
Накатывает патчи на EC2-инстансы
Ротрует логи приложения и вываливает их на S3.

Worker environment tier

Этот тип окружений предназначен для деплоя backend-слоя.
Elastic Beanstalk деплоит:

один или несколько инстансов EC2
AutoScaling Group
IAM-роль
Балансировщик
При необходимости - разворачивается очередь Amazon SQS

На каждый EC2-инстанс деплоится демон, который читает сообщения из очереди SQS и отправляет прочитанные данные в приложение.

IaC с помощью Amazon CloudFormation

Amazon CloudFormation - использует JSON-темплейты (можно YAML) для описания инфраструктуры, в коорые можно подставлять некоторые значения для изменения параметров.
Темплейты используются для разворачивания стеков - CloudFormation stacks

CloudFormation stacks

CloudFormation stack - это контейнер, который группирует создаваемые ресурсы и позволяет обращаться с ними как с единым целым.
Стеков в рамках инсталляции может быть много и они могут взаимодействовать между собой.

Change sets

При внесении изменений в ресурсы, задеплоенные с помощью CloudFormation формируются change set'ы, которые позволяют оценить изменения вносимые в конфигурацию и принять решение о файтическом изменении.
Это полезно, для избежания катастрофических последствий для инфраструктуры.
Например, если в темплейте поменять имя базы данных, то применение темплейта будет подразумевать удаление базы со старым именем и создание новой базы с новым именем.

Выявление отклонений - drift detection

Если в инфраструктуру вносятся изменения НЕ с помощью CloudFormation, то может возникать разница между тем, что описано в темплейтах и тем, что есть на самом деле.
Это может приводить к тому, что дальнейшее применение изменений с помощью CloudFormation может оказаться невозможным.
Для исправления этой ситуации существует механизм drift detection, который демонстрирует расхождения между фактической конфигурацией и тем что описано в темплейтах.

Управление конфигурацими с помощью Chef и Puppet на базе AWS OpsWorks

AWS OpsWorks for Puppet Enterprise и AWS OpsWorks for Chef Automate - это managed-сервисы, которые позволяют управлять конфигурациями инстансов EC2.

AWS OpsWorks Stacks

В рамках AWS стеком (stack) называется некоторый набор разнообразных ресурсов, управляемый как единое целое.
AWS OpsWorks Stack позволяет не толко создать и настроить ресурсы, но и мониторить их, при этом нет необходимости поддерживать инфраструктуру Chef для управления конфигурацией.
AWS OpsWorks Stack представлен двумя слоями (layers):

application layer - ресурсы необходимые собственно для работы приложения - инстансы EC2 и изх настройки - security groups и прочее
load balancing layer - балансировщики нарузки, которые распределяют трафик по инстансам EC2

Кроме того, стек AWS OpsWorks может быть расширен сервисыми слоями (service layers):

Amazon RDS layer - базы данных
Elastic Load Balancing layer - слой балансировщиков для организации отказоустойчивости и распределения нагрузки по нескольким AZ
Amazon ECS layer - слой для организации кластера и запуска в нем контейнеризированных приложений

13. Мониторинг и управление ресурсами AWS - Amazon CloudWatch

Базовые концепции Amazon CloudWatch

Amazon CloudWatch - предназначн для мониторинга, сбора, хранения и анализа метрик с ресурсов AWS, а также on-premises.
Все ресурсы AWS отдают метрики в CloudWatch. Базовый набор метрик - бесплатен, сложные метрики - за деньги.
Типичные задачи решаемые с помощью CloudWatch:

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

Метрики CloudWatch

Некоторые регулярно собираемые значения.
Каждая запись значения имеет таймстамп, а если его нет, то CloudWatch поставит ее сам.

Встроенные метрики - доступны “из коробки”. Например CPU, ввод-вывод и прочие.
Кастомные метрики - например время загрузки страниц веб-приложения или потребление памяти. Метрики могут собираться с помощью CloudWatch Agent (устанавливается на инстанс), либо пушиться c помощью метода CloudWatch API PutMetricData.

Записи метрики существуют в пределах региона AWS, но могут быть доступны в cross-account и cross-region дашбоардах.
Срок хранения - 15 месяцев. Старые записи автоматически уничтожаются.

CloudWatch Dashboards

Средства визуализации собранных данных метрик.
Функционал CloudWatch Dashboards интегрирован с AWS Organizations и таким образом является глобальным - межрегиональным и межаккаунтным.

CloudWatch Alarms

Средства реагирования на достижение мертиками заданных значений.
Alarm может иметь одно из трех состояний:

OK - значение метрики в пределах нормальных значений.
Alarm - достигнут заданный предел.
Insufficient Data - возвращается когда значений метрики недостаточно для принятия решения.

Возможные реакции на alarm:

Отправка сообщения через Simple Notification Service (SNS) - application-to-person - A2P (человеку) или application-to-application A2A (приложению)
Auto Scaling Action - сообщение для увеличения(уменьшения) числа EC2-инстансов.
EC2 action - действие с инстансом EC2, именно - запуск, остановка, рестарт, уничтожение, recovery (миграция на другой хост).
Публикация отметки на дашборд

CloudWatch Logs

Средство аггрегации логов, с ресурсов:

EC2-инстансы
CloudTrail logs
Route53 DNS
VPC flow
внешние ресурсы (логи приложений, логи ОС и прочие)

Время хранения логов настраивается (от 1 дня до 10 лет), но может быть и не ограниченным.
Логи могут архивироваться на S3 Glacier.
В подсистеме логирования можно выделить сущности:

События (Log Events) - запись о каком-то событии с меткой времени.
Потоки журналов (Log Streams) - Cloudwatch группирует последовательности записей логов от одного источника в потоки.
Группы журналов (Log Groups) - это несколько log streams с одинаковыи настройками (retention, access control).
Фильтры метрик (Metric Filters) - инструмент для извлечения метрик из логов, которые в дальнейшем могут использоваться в качестве кастомных метрик CloudWatch. Таким образом можно визуализировать определенные события и настроить реакцию на на них с помощью Alarms.

CloudWatch Events

CloudWatch Events - это устаревающий инструмент, который в настоящее время заменяется Amazon EventBridge.
Это инструмент, который позволяет создать правила, описывающие событие (запись в логах, время и т.д.), на которое можно настроить реакцию.
Реакция на возникновение события - практичесски в реальном времени, без задерджек.
Реакцию можно настроить на любую операцию API write. Примерами событий могут являться - выключение инстанса EC2, логин пользователя через IAM и прочее.
В качестве реакции могут выступать:

Lambda-функция
действие с инстансом EC2
сообщение в очередь SQS или SNS
ECS task
и другое.

Например - можно настроить выполнение Lambda-функции в ответ на событие загрузки файла на S3.

Amazon CloudTrail

Amazon CloudTrail - это средство аудита, которое может логировать все обращения к AWS API, таким образом фиксируя все действия пользователей и алгоритмов.
По-дефолту - включен. Время хранения записей - 90 дней.
Для просмотра собранного доступен CloudTrail Dashboard.
Логируются следующие разновидности событий:

Management Events (control plane events) - события записи/чтения AWS API
Data Events - операции над данными (напрмиер - в S3 или таблицах DynamoDB). Слежение за данными нужно включать специально.
Insight events - события связанные с необычными всплескми активности. Например - неожиданно возросшее число удалений из S3.

Trails

Trail - это специальный (отличный от дефолтного) конфиг CloudTrail, который фиксирует указанные события и хранит их заданный срок.
События пишутся в AWS S3, CloudWatch Logs и CloudWatch Events . Можно писать в один бакет, либо - в несколько.
В рамках одного Trail можно настроить хранение событий либо из одного региона, либо - из всех регионов (дефолтный вариант). При добавлении нового региона - его события автоматически добавляются в All Regions Trail.
Большинство событий - региональные и пишутся в том регионе, где произошли, а события глобальных сервисов (например - IAM) пишутся в дефолтный регион US East N.Virginia
Может быть настроен глобальный аудит в рамках корневого аккаунта организации - AWS Organization Trail, который будет фиксировать действия всех аккаунтов.

AWS Config

AWS Config - инструмент change management:

конфиг ресурсов
история конфига
взаимосвязи между ресурсами

Сущности, существующие в рамках AWS Config:

Configuration Item - это снепшот состояния конфигурации в заданный момент времени для одного заданного ресурса. Создается в момент внесения изменений и представляет собой файл JSON-diff между старым и новым состояниями.
Configuration History - это набор Configuration Item за заданный период времени - отражает историю изменений ресурса за указанный период.
Configuration Recorder - собственно сущность, которая фиксирует изменения. Должен быть включен в заданном регионе для всех или только для заданных типов ресурсов.
Configuration Snapshot - это набор Configuration Item для всех ресурсов. Отражает состояние всех ресурсов инфрастурктуры AWS.
Configuration Stream - набор Configuration Item, которые возникают по мере создания/изменения/удаления ресурсов и отправляются в топик Amazon SNS.

AWS System Manager

Инструмент для централизованного управления AWS. Ранее известен как SSM.
Позволяет декаларативно с помощью JSON-документов (есть много готовых темплейтов, но можно создавать и свои) приводить русурсы AWS к описанному в них сосотоянию.
Например - документ AWS-CreateRdsSnapshot позволяет быстро и просто создать снепшот базы данных.
Вот некоторые доступные операции:

Run Command - запуск shell-скриптов на EC2-инстансах под linux.
State Management - позволяет поддерживать конфиг инстансов в заданном сосотоянии. Например - состояние антивируса или файервола.
Inventory - позволяет собирать (инвентаризировать) информацию о софте на инстансах.
Maintenance Window - позволяет планировать обслуживание инстансов.
Patch Manager - автоматический деплой патчей.
Automation - автоматизация различных задач - обновление AMIs, создание снепшотов дисков, сброс паролей. запуск и уничтожение EC2-инстансов и всякое другое
Parameter Store - способ хранеия и доставки секретов (паролей и прочего).
Distributor - инструмент для создания и распространения дистрибутивов приложений.
Session Manager - способ доступа к shell инстансов, без необходимости открывать порты, SSH-ключи или настраивать бастионы.
Incident Manager - инструмент для расследования инцидентов и оповещения заинтересантов.

AWS Trusted Advisor

Сервис анализа конфигураций на соответствие best practice.
Модет выдавать репорты следующих категорий:

Cost Optimization - поиск неиспользуемых, но оплачиваемых ресурсов.
Performance - Поиск узких мест в плане производительности. Например - инстанс с высокимим запросами к диску имеет медленный gp2 диск.
Security - анализ настроек безопасности. Например - не включен MFA.
Fault Tolerance - анализ конфигурации на отказоустойчивость. Например - не включен Multi-AZ там где должен быть.
Service Limits - укащывает на скорое достижение лимитов. Например - при включенном AutoScaling.

Как должна выглядеть хорошо спроектированна инфрастуктура

Инфраструктуру принято оценивать по пяти критериям

Надежность

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

Производительность и эффективность

При проектировани инфраструктуры важно стремиться к заданому уровню производительности при оптимальной цене.
Также следует закладывать возможность расширения ресурсов при возрастающей нагрузке.
Следует планировать распределение ресурсов с учетом особенностей досиупа к приложениям - например - с учетом географии пользователей.

Безопасность

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

Операционное совершенство - Operational Excellence

Способность быстро и эффективно вносить обратимые изменения в конфигурацию в любой момент времени с помощью IaC.
Проведение тестов отказа элементов инфраструктуры и отработка реакции на их.
Выявление и устранение рисков.

Оптимизация расходов

Анализ структуры расходов на облачную инфраструктуру и автоматическая оптимизация потребления в зависимости от текущих условий.
Использование managed-решений.

14. Обеспечение безопасности инфрастурктуры AWS

Базовый принцип обеспечения безопасности AWS - Shared Responsibility Model. Она формулируется так:

AWS обеспечивает безопасность самого “облака”, а клиент обеспечивает безопасность ресурсов в облаке (путем корректной настройки).

Ответственность AWS - безопасность облака

Ответственность за:

Физическую безопасность инфраструктуры
Безопасность используемых протоколов
Обеспечение отказоустойчивости путем резервирования физических компонентов инфрастурктуры
Безопасность ПО, используемого для организации работы облака

Ответственность клиента - безопасность в облаке

Клиент несет ответственность за:

Конфигурирование приложений
Конфигурирование облачных ресурсов, которыми управляет клиент
Безопасность данных путем ограничения доступа к ним
Сохранность данных через резервного копирования

В зависимости от модели (IaaS, PaaS, SaaS) - объем ответственности клиента меняется.

Обеспечение соотвествия регулятивным требованиям - AWS Artifact

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

Сканирование на наличие уязвимостей

Amazon разрешает клиентам проводить pen-testing приложений, развернутых в среде AWS.
Есть некоторые типы проверок, которые могут проводить только организации со специальными полномочиями. Например - имитация атак Distributed Denial of Service (DDoS) разрешена только партнерам AWS Partner Network (APN).
Network Stress testing может осуществляться силами клиента, но с запросом соответствующего разрешения от AWS.

Обзор средств шифрования AWS

Передача данных по сети - должна проходить в зашифрованном виде по протоколам Secure Socket Layer/Transport Layer Security SSL/TLS.
Хранимые данные могут быть зашифрованы с помощью ключей и одного из признанных алгоритмов шифрования - Tripple DES или AES-256.
AWS может брать на себя задачи управления ключами шифрования - с помощью сервиса Key Management Service (KMS). С помощью KMS клиент создает Customer Master Keys (CMKs), которые зранятся в KMS и используются для шифрования.
Ключи могут быть мультирегиональными - то есть данные. зашифрованные в одном регионе, могут быть переданы и расшифрованы в другом.
Есть два типа ключей:

Customer-managed CMKs - клиент создает их и управляет ими (ротирует, назначает политики использования, тегирует, назначает алиасы).
AWS managed CMKs - ключами полностью управляет AWS.

AWS KMS интегрирован с CloudTrail и обеспечивает аудит использования ключей.

Шифрование Amazon S3

безопасность хранящихся на S3 данных может быть обеспечена следующими способами:

Server-Side Encryption - шифрование выполняет AWS при сохранении данных на диски и расшифровывает при считывании.
Client-Side Encryption - шифрование выполняется клиентом перед выгрузкой данных в S3 и клиент полностью контролирует ключи и средства шифрования.
Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3) - каждый объект шифруется уникальным ключем, а затем этот ключ шифруется мастер-ключем. AWS полностью берет на себя ротацию и обслуживание этих ключей.
Server-Side Encryption with CMKs Stored in AWS KMS (SSE-KMS) - аналогично SSE-S3, но ключи хранятся в KMS, что позволяет контролировать их использвание (кто и как использовал). Ключи уникальны для аккаунта, сервиса и региона.
Server-Side Encryption with Customer-Provided Keys (SSE-C) - ключами управляет клиент, а AWS шифрует данные на S3.

AWS KMS исползует дял шифрования аппаратные модули hardware security modules (HSMs), соответствующие стандарту FIPS 140-2. Модули HSM - используются многими клиентами AWS одновременно, но если нужно иметь выделенный модуль шифрования, то достун сервис AWS Cloud HSM.

AWS CloudHSM

Сервис AWS CloudHSM предоставляет досиуп к выделеному аппаратному модулю шифрования. который доступен в VPC. В этому случае - все операции к ключами (генерация, хранение, импорт, экспорт, ротация) выполняются клиентом.
Поддерживаются как симметрчное, так и ассимметричное шифрование.
AWS CloudHSM совместим с популярными API и библиотеками - PKCS#11, Java Cryptography Extension (JCE), Microsoft CryptoNG (CNG).

Защита облачных приложений с помощью AWS WAF и AWS Shield

Amazon WAF

Amazon WAF - это файервол приложений, который защищает приложения опубликованние через:

Amazon CloudFront
Amazon API Gateway
Amazon Application Load Balancers (ALB)
AWS AppSync GraphQL API

AWS WAF работает на Layer7 OSI, мониторит трафик HTTP/HTTPS и защищает от распространенных эксплоитов, а также от SQL-инъекций и XSS (cross-site scripting).
Настраивается с помощью web ACLs, которые задают правила проверок и реакции на результаты.
Биллинг - по числу правил web ACLs и HTTP(S)-запросов.

AWS Shield

AWS Shield - защита от DDoS.
Доступна в двух вариантах:

AWS Shield Stanard - бесплатная стандартная защита от наиболее распространенных атак. Может использоваться совместно с Amazon CloudFront и Route53.
AWS Shield Advanced - обеспечивает дополнительную защиту от атак на инстансы EC2, балансировщики ELB, CloudFront, Global Accelerator, Route53. Поддерживается автоматическое обнаружение атак и попвещение. Предоставляется круглосуточная поддержка со стороны AWS Shield Response Team (SRT). СТоимость - от $3000 за AWS Organization, а также - в зависимости от объема исходящих данных и используемых сервисов. В стоимость входят услуги AWS WAF

Защита инстансов EC2 с помощью AWS Inspector

AWS Inspector - проверяет инстансы EC2 с помощью двух наборов правил:

Network reachability rules package - проверят доступность хоста ин Internet и открытые порты.
Host Assessmentsrules package - проверка на опубликование уязвимости (CVE и CIS), и другие бест-практисы в части безопасности. Пароли рута и прочее.

Если нужна более развернутая информация о безопасности инстансов EC2 - на них предлагается установить AWS Inspector Agent. Он будет собирать информацию о ОС, приложениях, операциях на файловой системе и прочую телеметрию и выгружать ее на S3 в виде JSON-документов. Затем - на основании этих документов могут быть сформулированы рекомендации.
Установить AWS Inspector Agent удобно с помощью AWS System Manager Run Command.

Другие сервисы AWS, обеспечивающие безопасность

AWS Macie

Сервис проверки данных на наличие сенситивной информации. Например - персональных данных.
Сканирует данные на S3 и определет подозрительные паттерны, а также - мониторит доступ к данным на S3 и выявляет аномалии или неавторизованный доступ.

AWS GuardDuty

AWS GuardDuty - серсив обнаружения угроз с помощью анализа подозрительной активности аккаунтов AWS и приложений. Анализирует данные из логов - CloudTrail Logs, VPC Flow Logs, DNS.
Обнаруживает использование скомпроментированных учетных данных, взаимодейтстсвие с подозрительными IP и доменами, необычную активность учеток AWS.
Например - запуск EC2-инстансов в регионах, где обычно комапния не работает.
Обнаруживает криптовалютные майнеры, компроментацию бакетов S3 и прочее.

Биллинг - в зависимости от числа событий логов CloudTrail, VPC Flow, DNS.

Amazon Detective

Сервис помогает в расследовании инцидентов и поиске первопричин инцидентов - позволяет визуализировать, анализировать и сопоставлять логи CloudTrail, VPC Flow, результаты работы GuardDuty.

AWS Certification Manager

Сервис управления (получение, обновление) сертификатами. Интегрирован с балансировщиками и CloudFront.

AWS Secrets Manager

Сервис AWS Secrets Manager немного напоминает AWS System Manager Parameter Store, однако не только модет хранить сенситивные данные, но и автоматически ротировать. например - пароли от баз Amazon RDS.
Или - токены для взаимной аутентификации приложений.
Кроме того - AWS Secrets Manager шифрует хранимые данные с помощью ключей Amazon KMS и обеспечивает репликацию секретов между регионами.
Биллинг - в зависимости от числа ключей и вызовов Secrets Manager API.

Amazon Cognito

Amazon Cognito - сервис аутентификации пользователей опубликованных приложений по протоколам OAuth, SAML, OpenID и прочие.
Внутри Amazon Cognito есть две сущности отвечающие за аутентификацию и авторизацию соотвественно:

Amazon Cognito User pools - Это источник учеток. Congnito может сам хостить и аутентифицировать учетки или брать их из присоединенных источников (Apple, Google, Facebook, MS AD LDAP и прочие) и аутентифицировать там.
Amazon Cognito Identity Pools - средство создания identity и раздачи прав на ресурсы AWS для пользователей, подлинность учетных данных которых были подтверждены в Cognito User Pool. Кроме того - может создавать временные identity для анонимных пользователей.

AWS Directory Service

AWS Directory Service for Microsoft Active Directory (также известен как AWS Managed Microsoft AD) - это fully-managed Active Drectory на платформе AWS.
Позволяет использовать MS AD аутентификацию на всех сервисах AWS, которые это умеют.
В том числе Amazon Workspaces - VDI на базе linux и windows, также Amazon Worksdocs - облачный офисный пакет от Amazon, совместимый с продуктами Microsoft.

15. Биллинг и ценообразование

Пользователь платит за:

вычислительные мощности
хранение информации
исходящий сетевой трафик

При проектировании решений следует принимать ко вниманию:

Выбор модели ценообразования на вычислительные ресурсы - то есть определиться с тем нужны ли гарантированные инстансы On-Demand, или можно выбрать негарантированные Spot, которые позволят сэкономить до 72% стоимости. Либо - при заключении соглашения на обязательное минимальное количество потребляемых ресурсов можно ориентироваться на compute savings plans.
Выбор правильного количества заказываемых ресурсов. Чтобы не переплачиваь нужно правильно понимать сколько чего нужно, Для этого AWS предоставляет специальные инструменты - AWS Cost Explorer, который позволяет выявить ресурсы с низкой утилизацией. Также с помощью AWS CloudFormation планировать включение/выключение инстансов по расписанию.
Мониторинг и выявление фактического потребления на основе метрик CPU, ввода-вывода, памяти. В этом помогут CloudWatch для большинстава ресурсов и Amazon S3 analytics для выявлния паттернов обращения к ресурсам на S3.

AWS Cost Explorer

Средство мониторинга и визуализации затрат. Позволяет увидеть на что тратятся деньги и спрогнозировать траты на год вперед.
Можно видеть затраты по часам и по разным типам ресурсов.
AWS Cost Explorer выдет рекомендации на основе которых можно резервировать ресурсы и таким образом экономить.
Также - позволяет выявлять аномалии в затратах и оповещать о них

Тегирование ресурсов

Для выделения среди ресурсов групп и определения того какие из этих групп сколько стоят применяются теги. Теги бывают встроенные и пользовательские.

AWS Budgets

Позволяют мониторить затраты и предпренимать действия при превышении заданных поргов:

Применять IAM-политики
Service Control Policies
Что-то делать непосредственно с инстансами (EC2 или RDS)

То есть, например при превышении бюджета можно запретить создание новых EC2-инстансов с помощью IAM-политики.

aws_certified_devops_engineer_professional

anonymous@undisclosed.example.com (Anonymous) — Thu, 07 Jul 2022 06:05:51 +0000

Тут я оставляю заметки при подготовке к экзамену AWS Certified DevOps Engineer Professional - DOP-C01

Пять критериев качественной инфрастуктуры

Операционное совершенство - Operational Excellence

Наиболее важный критерий в повседневной работе.
Включает в себя пять основных принципов работы с инфрастурктурой:

Использование Infrastructure As Code. Способствует распространению знаний об инфрастурктуре, оценке её качества и позволяют быстро тестировать изменения. AWS предлагает несколько инструментов: CloudFormation, Cloud Development Kit (CDK), различные SDK и интерфейс CLI.
Быстрая реакция на события и инциденты.
Внесение частых, небольших и обратимых изменений в инфраструктуру.
Предсказание проблем и отказов и действия на опережение.
Извлечение знаний из инциденнтов и ииспользование их в дальнейшем

Пример реализации операционного совершенства

Например - есть набор ec2-инстансов, которые требуют обновлений.
Для установки патчей можно использовать Patch Manager из состава System Manager. Регулярные обновления реализуются с помощью System Manager Maintenance Task.
Вот что нужно сделать для реализации этой задачи:

убедиться, что на всех инстансах развернут SSM Agent (бывший Simple System Manager).
Создать алгоритм обновления (patching baseline), содержащий правила для аппрува/отказа списков патчей
измениь IAM-role инстансов, чтобы SSM на них имел нужные привилегии
опционально создать группы серверов (patch managenment groups), на которые устанавливаются разные наборы обновлений.

Безопасность

Обеспечение безопасности включает в себя четыре области:

защита данных
Управление привилегиями
Реакция на инциденты
Расследование инцидентов

В свою очередь хорошо српоектированная сисьема должна следовать семи принципам безопасности:

Строгая идентификация (strong identity foundation) и следование принципу наименьших необходимых привилегий (AWS IAM, AWS Single Sign-On, Active Directory)
Возможность проследить взаимосвязанные события (traceability) (AWS CloudWatch Logs, AWS VPC Flow Logs, AWS CloudTrail)
безопасность на всех уровнях взаимодействия (Security Groups, Network ACLs, etc…)
автоматизация процедур, обеспечивающих безопасность (GuardDuty, CloudWatch, EventHub, AWS Config)
защита данных в процессе передачи и хранения (Certificate Manager, AWS Shield, AWS Web Application Firewall, Amazon CloudFront, Key Management Service)
отсутствие прямого доступа людей к данным
готовность к событиям безопасности - создание и поддержание в актуальном состоянии планов на случай нежелательных событий

Надежность

Пять основных принципов обеспечения надежности:

Автоматизация процедур восстановления после сбоев
Регулярное тестирование процедур восстановления
Горизонтальное масштабирование для повышения общей доступности сервисов
Правильное планирование ресурсов
Автоматизация рутинных процедур

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

Производительность и эффективность

При проектировани инфраструктуры важно стремиться к заданому уровню производительности при оптимальной цене. Также следует закладывать возможность расширения ресурсов при возрастающей нагрузке. Следует планировать распределение ресурсов с учетом особенностей досиупа к приложениям - например - с учетом географии пользователей.

Оптимизация расходов

Анализ структуры расходов на облачную инфраструктуру и автоматическая оптимизация потребления в зависимости от текущих условий. Использование managed-решений.

aws_end_to_end_pipeline

anonymous@undisclosed.example.com (Anonymous) — Sun, 04 Sep 2022 09:26:55 +0000

https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/

aws_k8s_eks_lb_conroller

anonymous@undisclosed.example.com (Anonymous) — Tue, 08 Nov 2022 14:28:13 +0000

https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html

aws_rds_performance

anonymous@undisclosed.example.com (Anonymous) — Wed, 05 Feb 2025 09:01:56 +0000

https://aws.amazon.com/blogs/database/resources-consumed-by-idle-postgresql-connections/

aws_s3_upload_using_bash

anonymous@undisclosed.example.com (Anonymous) — Tue, 21 Jun 2022 13:17:06 +0000

#!/bin/bash
set -e
set -u

S3_BUCKET='super-bucket'
S3_URL='storage.yandexcloud.net'
S3_KEY='SUPERSECRET'
S3_SECRET='SUPERSECRET'
LOG_FILE_PATH=$1
LOG_FILE=`basename $LOG_FILE_PATH`

S3_RESOURCE="/${S3_BUCKET}/${LOG_FILE}"
S3_CONTENT_TYPE="application/json"
S3_DATE_VALUE=`date -R`
S3_STRING_TO_SIGN="PUT\n\n${S3_CONTENT_TYPE}\n${S3_DATE_VALUE}\n${S3_RESOURCE}"
S3_SIGNATURE=`echo -en ${S3_STRING_TO_SIGN} | openssl sha1 -hmac ${S3_SECRET} -binary | base64`
echo "Uploading ${LOG_FILE_PATH} to https://${S3_BUCKET}.${S3_URL}/${LOG_FILE}"
curl -s -L -X PUT -T "${LOG_FILE_PATH}" \
  -H "Host: ${S3_BUCKET}.${S3_URL}" \
  -H "Date: ${S3_DATE_VALUE}" \
  -H "Content-Type: ${S3_CONTENT_TYPE}" \
  -H "Authorization: AWS ${S3_KEY}:${S3_SIGNATURE}" \
  https://${S3_BUCKET}.${S3_URL}/${LOG_FILE} > /dev/null 2>&1 || echo "Upload Failed !!!"

aws_using_nat_gateways

anonymous@undisclosed.example.com (Anonymous) — Mon, 08 Aug 2022 13:57:50 +0000

Задача

Для обеспечения безопасности нужно, чтобы запросы от сервисов, работащих в AWS EKS приходили с фиксированных адресов.
Дефолтный вариант доступа в интернет - это через Internet Gateway, а он не обспечивает стабильность IP-адреса для исходящих запросов.
Ноды моего k8s-кластера размещены в трех AZ.

Как это должно быть сделано

Это делается с помощью NAT Gateways.

Порядок действий

Сделать каждой AZ по приватной сети. В дополнение к имеющимся дефолтным публичным сетям. Приватной сеть становится, кгда лишается записи дефолтного маршрута (0.0.0.0/0) через Internet Gateway в Routing Table
Чтобы сделать сети приватными - идем в VPC → Routing Tables и создаем три таблицы (по одной на каждую подсеть). В каждой из таблиц - есть только один маршрут - local. Жмем Edit Subnet Associations и ставим галочку на соотвествующей только что созданной подсети. В итоге - у нас есть три новых подсети и таблицы маршрутизации для них, в которых есть только маршрут local - то есть они приватные.
Теперь нужно создать три NAT Gateway типа Public. При создании - указываем для них ПУБЛИЧНЫЕ сети (не те, которые были созданы на первом этапе), а также им нужны - Elastic IP (поле Elastic IP allocation ID)
Теперь нужно добавить в созданные Routing Tables маршрут для Destination 0.0.0.0/0, указывающий на соотвествующий NAT Gateway.

awx_программное_обновление_опросов_progammatic_survey

anonymous@undisclosed.example.com (Anonymous) — Fri, 10 Jun 2022 11:48:54 +0000

Программируемые опросы AWX

Программируемые опросы используются для удобного заполнения значений переменных для плейбуков ansible.
В данный момент - опросы могут быть заполнены только с помощью tower-cli.

Все запросы на эту фичу стекаются сюда: https://github.com/ansible/awx/issues/20
Для того, чтобы динамически формировать выпадающий список опроса (dynamic entries in multi-choice survey drop-down menu) умный человек запилил хак: https://github.com/ansible/awx/pull/1408 , но этот вариант применим не ко всем версиям AWX
Вот тут есть немного полезного: https://groups.google.com/forum/#!topic/awx-project/cuDsbk3lFA4

Псевдо динамический вариант опроса

Управлять спецификацией опроса можно через API.
Вот по такому пути https://awx.domain_local/api/v2/job_templates/12/survey_spec/ можно получить доступ к спецификации опроса, прочитать ее, изменить и записать с помощью POST HTTP-реквеста. Теоретически. В веб-интерфейсе есть для этого всё.
Также, можно воспользоваться tower-cli.
Мне нужно автоматически заполнять список файлов бекапа, из которых пользователь выберет нужный и восстановит базу, запустив плейбук.
Так как список файлов обновляется не часто, то я могу написать скрипт, который будет исполняться по таймеру, опрашивать папку и при обновлении списка файлов - вносить изменения в спецификацию опроса.

настройка tower-cli

https://docs.ansible.com/ansible-tower/latest/html/towerapi/tower_cli.html
Устанавливаем:

sudo pip3 --proxy=http://192.168.104.94:3130 install ansible-tower-cli

Настраиваем tower-cli

sudo mkdir /etc/tower/
sudo tower-cli config --global host https://awx.rdleas.ru
sudo tower-cli config --global username admin
sudo tower-cli config --global password __passwd__
sudo tower-cli config --global verify_ssl false

В результате, параметры доступа к AWX попадут в файл /etc/tower/tower_cli.cfg, доступный только для чтения root.
Проверяем:

sudo tower-cli user list

https://github.com/ansible/tower-cli/blob/master/docs/source/cli_ref/usage/SURVEYS.rst
Смотрим текущее состояние survey для данного job_template:

tower-cli job_template survey -n 'job template name'

Сохранение спецификации survey в файл:

tower-cli job_template survey --name="survey jt" > s.json

Загрузка job survey из файла:

tower-cli job_template modify --name="another jt" --survey-spec=@s.json --survey-enabled=true

Вот скрипт на питоне, который заполняет поля мультичойса для заданного вопроса:

#!/usr/bin/python

import json
import os    
import random
import string

######################
smb_creds='/etc/tower/smbcredentials.conf' 
backup_share_path='\\\\\\\\backup01\\\\sql' 
backup_folder='\\\\SRV-NAV18-SQL\\\\ASR_PROD\\\\'
survey_name='SBL Deploy ASOR Test Environment'
survey_question='DataBase backup file path'
#####################

cmd = 'smbclient ' + backup_share_path + ' -D ' + backup_folder + ' -A ' + smb_creds + ' -c ls 2>/dev/null | awk \'{print $1}\' | grep -e \'^\..*$\' -v | grep \'.bak\''
choices = ""

for file in os.popen(cmd).readlines():
    choices = choices + '\n' + backup_share_path + backup_folder + file.rstrip()
choices = choices[2:]
choices = choices.replace('\\\\','\\')

cmd = 'tower-cli job_template survey -n "' + survey_name + '"'
survey_content = os.popen(cmd).read()

survey_obj = json.loads(survey_content)

for question in survey_obj['spec']:
    if question["question_name"] == survey_question:
       question["choices"] = choices

filename='/tmp/' + ''.join(random.choice(string.ascii_uppercase + string.digits) for _ in range(5)) + '.json'
f = open(filename, "w")
f.write(json.dumps(survey_obj, sort_keys=True, indent=4))
f.close()

cmd = 'tower-cli job_template modify -n "' + survey_name + '" --survey-spec=@' + filename + ' --survey-enabled=true'

survey_mod = os.popen(cmd).read()
os.remove(filename)

Вот скрипт, который берет данные с Windows-хоста, используя PowerShell и помещает результат в поля AWX Survey.

#!/usr/bin/python2

from __future__ import print_function
import winrm
import json
import os
import random
import string

survey_name='SBL Navision Instance Automation'
survey_question='Select Navision Instance'

nav_server_list = [
'srv-nav2017-dev',
'srv-nav2017-tst'
]
win_user = 'web_nav_develop@RDLEAS.RU'
win_pass = 'n2n?yJ76cn!CvLMX'
winrm_transport='ntlm'

ps_script = """
    Import-Module "C:\Program Files\Microsoft Dynamics NAV\\110\Service\NavAdminTool.ps1" *>&1 | out-null
    foreach ($instance in $(Get-NAVServerInstance))
    {
        Write-Host "$env:computername - $(($instance.ServerInstance).ToString().Split('$')[1]) - $($instance.State.ToString())"
    }
"""
choices = ""
for nav_server in nav_server_list:
        win_host = 'http://'+ nav_server + ':5985/wsman'
        s = winrm.Session(win_host, auth=(win_user, win_pass), transport=winrm_transport)
        r=s.run_ps(ps_script)
        #print (r.status_code)
        #print (r.std_err)
        if r.status_code == 0:
           for instance in r.std_out.splitlines():
                choices = choices + '\n' + instance
choices = choices[1:]

cmd = 'tower-cli job_template survey -n "' + survey_name + '"'
survey_content = os.popen(cmd).read()

survey_obj = json.loads(survey_content)

for question in survey_obj['spec']:
    if question["question_name"] == survey_question:
       question["choices"] = choices

filename='/tmp/' + ''.join(random.choice(string.ascii_uppercase + string.digits) for _ in range(5)) + '.json'
f = open(filename, "w")
f.write(json.dumps(survey_obj, sort_keys=True, indent=4))
f.close()

cmd = 'tower-cli job_template modify -n "' + survey_name + '" --survey-spec=@' + filename + ' --survey-enabled=true'

survey_mod = os.popen(cmd).read()
os.remove(filename)

Подготовка хоста для исполнения текущих скриптов для динамических опросов AWX

sudo apt-get install gcc python3-dev python-dev libkrb5-dev

Проверить, что в файлике /usr/bin/pip2 используется в качестве интерпретатора указан python2

sudo pip3 --proxy=http://192.168.104.94:3130 install pywinrm pyjson pyrandom
sudo pip2 --proxy=http://192.168.104.94:3130 install pywinrm pyjson pyrandom
sudo pip2 --proxy=http://192.168.104.94:3130 install pywinrm[kerberos]
sudo pip3 --proxy=http://192.168.104.94:3130 install pywinrm[kerberos]

bare_metal_kubernetes_persistent_volume_dynamic_provisioning

anonymous@undisclosed.example.com (Anonymous) — Thu, 28 Apr 2022 13:30:31 +0000

Динамический провижининг Persistent Volumes в bare-metal инсталляциях kubernetes

OpenEBS

Имеет под капотом несколько различных движков, которые обеспечивают различный уровень производительности/отказоустойчивости. Некоторые движки умеют репликацию, но также есть простой DynamicLocal PV. OpenEBS

https://habr.com/ru/company/flant/blog/503712/

Local Persistence Volume Static Provisioner

https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner

git clone --depth=1 https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner.git
kubectl create ns pv-provisioner
helm upgrade --install -n pv-provisioner local ./sig-storage-local-static-provisioner/helm/provisioner \
 --set common.mountDevVolume="false" \
 --set classes[0].name="rmq" \
 --set classes[0].hostDir="/var/lib/rmq" \
 --set classes[0].volumeMode="Filesystem" \
 --set classes[0].storageClass="true" \
 --set classes[1].name="default" \
 --set classes[1].hostDir="/var/lib/kubernetes_volumes" \
 --set classes[1].volumeMode="Filesystem" \
 --set classes[1].storageClass.isDefaultClass="true" \
 --set classes[2].name="redis" \
 --set classes[2].hostDir="/var/lib/redis" \
 --set classes[2].volumeMode="Filesystem" \
 --set classes[2].storageClass="true"

Как Local Static Volumes Provisioner работает

Local Static Volumes Provisioner следит за указанной в конфиге директорией на хостах кластера и все смонтированные в эти дииректории блочные устройства представляет в кубере как PV.
То есть, чтобы сделать PV нужно:

Создать на ноде LogicalVolume
Отформатировать его в ext4
Смонтировать в заданной директории

Для данных на нодах есть пустой диск /dev/sdb.
Подотовим его:

sudo yum install gdisk
sudo sgdisk -p /dev/sdb
sudo sgdisk -n 1:2048:0 /dev/sdb
sudo sgdisk -t 1:8E00 /dev/sdb
sudo pvcreate /dev/sdb1

И создадим VolumeGroup - data

sudo vgcreate data /dev/sdb1

Теперь можно создавать LogicalVolumes и монтировать их:

sudo lvcreate -L6.3G -nelk-master-0 data
sudo mkfs.ext4 /dev/data/elk-master-0
sudo mkdir /var/lib/kubernetes_volumes/elk-master-0
sudo mount /dev/data/elk-master-0 /var/lib/kubernetes_volumes/elk-master-0

building_and_publishing_deb_package_on_launchpad_using_github_actions

anonymous@undisclosed.example.com (Anonymous) — Mon, 21 Jun 2021 07:21:18 +0000

Регистрируемся на launchpad.net и создаем ppa

Если еще нет учетки на Ubuntu One или Launchpad.net, то идем на https://login.launchpad.net и регистрируемся и логинимся.
Теперь Создаем новый проект на launchpad - https://launchpad.net/projects/+new .
На первом этапе - вводим Имя проекта и краткое описание.
Затем - Launchpad услужливо спросит, нет ли подобного проекта среди уже существующих - отвечаем No, this is a new project.
Ну и заполняем то что он спросит - там не сложно.
Дальше - на своей страничке (URL - https://launchpad.net/~{USERNAME}) жмем Create a new PPA (или идем по ссылке типа https://launchpad.net/~{USERNAME}/+activate-ppa)

Генерация ключа pgp

Делаем как написано тут: https://help.ubuntu.com/community/GnuPrivacyGuardHowto

gpg --gen-key

Вводим имя и e-mail, затем - пароль и получаем ключ.
В выводе будет что-то такое:

pub   rsa3072 2021-06-19 [SC] [expires: 2023-06-19]
    B7569B57852DF8B47BFE5D7D3DC913AE67653CD3

А именно - fingreprint ключа - B7569B57852DF8B47BFE5D7D3DC913AE67653CD3. У вас он будет другой.
Теперь делаем его ключем по-умолчанию. Для этого редактируем ~/.bash_profile и прописываем там fingreprint ключа:

export GPGKEY=B7569B57852DF8B47BFE5D7D3DC913AE67653CD3

Ну и для работы в текущей локальной сессии выполним:

export GPGKEY=B7569B57852DF8B47BFE5D7D3DC913AE67653CD3

Загрузим ключ на сервер:

gpg --send-keys --keyserver keyserver.ubuntu.com $GPGKEY

Добавим ключ в PPA: https://launchpad.net/~~{USERNAME}/+editpgpkeys и там то самое $GPGKEY.
В результате - на почту придет сообщение зашифрованное данным ключем, которое нужно расшифровать и перейти поссылке.
Для этого - открывам письмо, ищем текст, который начинается примерно так:

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1

hQGMAwlc3LxvNLEXAQwAnPnvIBNfGsY6cOkbc+MIHYFoMJknmRRICXEkwMbdmwoC
FFpq7LTzMmDWzleelg/XGJBEfnLs8aVsSgfDPqg2LCBEXRxOjCG7+COohDBHq1cN
....

И подствляем его в команду:

echo '-----BEGIN PGP MESSAGE-----
Version: GnuPG v1

hQGMAwlc3LxvNLEXAQwAnPnvIBNfGsY6cOkbc+MIHYFoMJknmRRICXEkwMbdmwoC
FFpq7LTzMmDWzleelg/XGJBEfnLs8aVsSgfDPqg2LCBEXRxOjCG7+COohDBHq1cN
...
wfa+c9quFl6ZBBFfAlteXi4ZqeVTLkuZdCqRcmlAxANyu4hpKytwMk0TnYXpdCZ8
TKrP/pWEVB/wrRt60ZKPNv/dShoHiyiuCgQxapWIKOfNS5Vh1tnoQJmfCD4xUn0a
KfXT8528u6o=
=5CDZ
-----END PGP MESSAGE-----' | gpg --decrypt

Вводим пароль от ключа и получаем текст письма, в котором - ссылка вида: https://launchpad.net/token/H4Mvs.... Переходим по ней изавершаем добавление ключа - жмем Continue.

Добавление ключа в GitHub Actions

https://github.com/marketplace/actions/import-gpg
Извлечем закрытый ключ:

gpg --armor --export-secret-key kind.devops@gmail.com -w0

Чтобы добавить ключ GPG в проект и использовать его при публикации - идем в проект на GitHub → Settings → Secrets → New Repository Secret и создаем пару секретов - GPG_PRIVATE_KEY и GPG_PASSPHRASE соответственно с приватным ключем и паролем.

Сборка deb-пакета и загрузка его на launchpad ppa

http://www.hackgnar.com/2016/01/simple-deb-package-creation.html
https://blog.packagecloud.io/debian/debuild/packaging/2015/06/08/buildling-deb-packages-with-debuild/

build_docker_images_in_k8s_cluster

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Feb 2022 12:57:55 +0000

Задача - сбилдить образ docker имея только доступ к k8s-api.

Запускаем контейнер с Docker-in-Docker:

kubectl run -it --rm --privileged --image docker:dind dind -- /bin/sh -c 'unset DOCKER_TLS_CERTDIR && dockerd-entrypoint.sh & echo "127.0.0.1 docker" >> /etc/hosts & /bin/sh'

Забираем из git репу с докерфайлом:

apk add git
git clone ...

билдим

docker build .

build_rpm_from_python_script

anonymous@undisclosed.example.com (Anonymous) — Wed, 02 Mar 2022 09:15:06 +0000

Полезные URL

https://github.com/vinta/awesome-python#distribution - список тулзов, которые используются для упаковки скриптов python в устанавливаемые пакеты.

Задача

Упаковать скрипт в rpm-пакет со всеми зависимостями, чтобы установка этого скрипта не влияла на python-пкеты на целевой системе.

cadvisor

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Mar 2022 12:41:31 +0000

Метрики cadvisor

curl -k --key /var/lib/kubelet/pki/kubelet-client-current.pem --cert /var/lib/kubelet/pki/kubelet-client-current.pem --cacert /etc/kubernetes/pki/ca.crt https://0.0.0.0:10250/metrics/cadvisor

cka_preparation

anonymous@undisclosed.example.com (Anonymous) — Wed, 01 Mar 2023 10:31:11 +0000

Примеры вопросов

cyber_security

anonymous@undisclosed.example.com (Anonymous) — Mon, 10 Jul 2023 06:33:00 +0000

Разведка

Собираем информацию о:

Обнаружение доменных имен, принадлежащих организации
Обнаружение “живых” хостов в сети и составления списка их IP-адресов
Определение актуального статуса сетевых портов узлов из списка
Определение типа и версии операционной системы на исследованных машинах
Определение версий ПО или служб, которые находятся на сетевых портах
Сбор информации об используемых технологиях на веб-сайте

DNS-имена

команда host
https://dnsdumpster.com - информация о DNS-именах
сайт https://crt.sh - информация о сертификатах
инструмент amass - опрашивает разные базы и получает сведения о домене и связанных с ним именах, сертификатах и прочем. Также умеет генерить запросы к DNS для обнаружения доменных имен в заданной зоне.
сканеры поддоменов Sublist3r и assetfinder
https://spark-interfax.ru/
https://apps.db.ripe.net/db-web-ui/fulltextsearch
shodan.io
censys.io
pentest-tools.com
https://osintframework.com/
Сисок инструментов: https://github.com/jivoi/awesome-osint

Сканеры портов

nmap (Zenmap) Материалы: Mastering Nmap Scripting Engine, Nmap Network Scanning, Nmap 6: Network Exploration and Security Auditing Cookbook
massscan

Статусы открытости портов

Важно понимать, что любые инструменты будут описывать сетевые порты определенными статусами. В соответствии с утилитой Nmap существует шесть состояний сетевых портов :

открыт (open) - Приложение принимает запросы на TCP соединение или UDP пакеты на этот порт. Обнаружение этого состояния обычно является основной целью сканирования. Люди, разбирающиеся в безопасности, знают, что каждый открытый порт — это прямой путь к возможному взаимодействию. Атакующие хотят использовать открытые порты, а администраторы пытаются закрыть их или защитить с помощью брандмауэров так, чтобы не мешать работе обычных пользователей. Открытые порты также интересны с точки зрения сканирования, не связанного с безопасностью, т.к. они позволяют определить службы, доступные в сети.
закрыт (closed) - Закрытый порт доступен, но не используется каким-либо приложением. Этот статус может означать, что по заданному IP адресу есть существующий узел, или помогать определять ОС. Т.к. эти порты достижимы, может быть полезным произвести сканирование позже, т.к. некоторые из них могут открыться. Администраторы могут заблокировать такие порты с помощью брандмауэров, тогда их состояние будет определено как “фильтруется”.
фильтруется (filtered) - Нельзя определить, открыт ли порт, т.к. фильтрация пакетов не позволяет достичь запросам Nmap этого порта. Фильтрация может осуществляться выделенным брандмауэром, правилами роутера или брандмауэром на целевой машине. Эти порты бесполезны для атакующих, т.к. предоставляют очень мало информации. Иногда они отвечаютICMPсообщениями об ошибке, такими, как тип 3 код 13 (destination unreachable: communication administratively prohibited (англ.: цель назначения недоступна: связь запрещена администратором), но чаще встречаются фильтры, которые отбрасывают запросы без предоставления какой-либо информации. Для этого нужно сделать еще несколько запросов, чтобы убедиться, что запрос был отброшен фильтром, а не затором в сети. Это очень сильно замедляет сканирование.
не фильтруется (unfiltered) - Это состояние означает, что порт доступен, но нельзя определить, открыт он или закрыт. Только ACK сканирование, используемое для определения правил брандмауэра, может охарактеризовать порт этим состоянием. Сканирование не фильтруемых портов другими способами, такими, как Windows сканирование, SYN сканирование или FIN сканирование, может помочь определить, является ли порт открытым.
открыт|фильтруется (open|filtered) - Порт характеризуется таким состоянием, когда нельзя определить, открыт порт или фильтруется. Это состояние возникает при таких типах сканирования, при которых открытые порты не отвечают. Отсутствие ответа также может означать, что пакетный фильтр не пропустил запрос или ответ не был получен. Порт может быть охарактеризован таким состоянием при сканировании UDP, по IP протоколу, FIN, NULL, а также Xmas.
закрыт|фильтруется (closed|filtered) - Это состояние используется, когда нельзя определить, закрыт порт или фильтруется. Используется только при сканировании IP ID idle типа.

deploy_elk_using_helm

anonymous@undisclosed.example.com (Anonymous) — Sun, 24 Oct 2021 12:06:27 +0000

Add elastic repo

helm repo add elastic https://helm.elastic.co

Install Elasticsearch

Create namespace

kubectl create ns elasticsearch

deploy Elasticsearch from helm

helm install --namespace elasticsearch --name elasticsearch elastic/elasticsearch --set replicas=1

Create Persistent Volume for Elasticsearch

sudo mkdir /kubernetes_volumes/elasticsearch-data
sudo chmod a+rw -R /kubernetes_volumes/elasticsearch-data/

apiVersion: v1
kind: PersistentVolume
metadata:
   name: elasticsearch-data
   namespace: elasticsearch
   labels:
     app: elasticsearch-master
spec:
  capacity:
    storage: 32Gi
  accessModes:
  - ReadWriteOnce
  hostPath:
    path: "/kubernetes_volumes/elasticsearch-data"
    type: Directory
  persistentVolumeReclaimPolicy: Retain

И дадим права на запись в индексы:

kubectl exec -it -n elasticsearch elasticsearch-master-0 -- curl -XPUT -H "Content-Type: application/json" http://localhost:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}'

Так как нода у меня одна, то мне нужно запретить создавать реплики. Иниче - в дальнейшем кластер просто перестанет работать:

kubectl exec -it -n elasticsearch elasticsearch-master-0 -- curl -H "Content-Type: application/json" -XPUT 'http://127.0.0.1:9200/_template/default' -d '{"index_patterns": ["*"],"order": -1,"settings": {"number_of_shards": "1","number_of_replicas": "0"}}'

И почистим уже созданные индексы:

kubectl exec -it -n elasticsearch elasticsearch-master-0 -- curl -XDELETE 'http://127.0.0.1:9200/*'

Теперь в логах пода elasticsearch-master-0 появится строка:

Cluster health status changed from [YELLOW] to [GREEN]

И в этот elasticsearch можно будет писать логи.

Install Kibana

kubectl create ns kibana
helm install --namespace elasticsearch --name kibana elastic/kibana --set elasticsearchHosts=http://elasticsearch-master.elasticsearch.svc.cluster.local:9200

  helm upgrade kibana elastic/kibana --set elasticsearchHosts=http://openresty-oidc-http.elasticsearch.svc.cluster.local:9200 --set elasticsearch.requestHeadersWhitelist=[X-Auth-Username]

Kibana Ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: letsencrypt
  name: kibana-ingress
  namespace: elasticsearch
spec:
  rules:
  - host: kibana.autosys.tk
    http:
      paths:
      - backend:
          serviceName: kibana-kibana
          servicePort: 5601
        path: /
  tls:
  - hosts:
    - kibana.autosys.tk
    secretName:  kibana-autosys-tk-tls

Kibana Saved Objects

В кибане есть сохраненные пользователем объекты. Например - Index Patterns.
Создать можно так:

kubectl exec -it -n elk elk-openresty-oidc-559f46d69d-shbwg -- curl -H 'Authorization: Basic dXN....o' -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d '{"attributes": {"title": "my-pattern-*"}}' http://elk-kb-http:5601/api/saved_objects/index-pattern/my-pattern

Посмотреть их можно так:

kubectl exec -it -n elk elk-openresty-oidc-559f46d69d-shbwg -- curl -H 'Authorization: Basic dXN....o' http://elk-kb-http:5601/api/saved_objects/_find?type=index-pattern | grep '"type":"index-pattern"'

Удалить какой-то можно так:

kubectl exec -it -n elk elk-openresty-oidc-559f46d69d-shbwg -- curl -X DELETE -H 'kbn-xsrf: true' -H 'Authorization: Basic dXN....o' http://elk-kb-http:5601/api/saved_objects/index-pattern/vrm

Logstash

https://habr.com/ru/post/421819/
https://helm.elastic.co/

helm install --namespace elasticsearch --name logstash elastic/logstash -f ./values.yaml

Настройка rsyslog и фильтра logstash

У меня rsyslog сыплет логи в таком виде:

Dec 25 14:06:25 kub kubelet[989]: W1225 14:06:25.516800     989 volume_linux.go:45] Setting volume ownership for /var/lib/kubelet/pods/d36eb244-fe63-4f5d-b133-c4e4232c68b3/volumes/kubernetes.io~configmap/sc-dashboard-provider and fsGroup set. If the volume has a lot of files then setting volume ownership could be slow, see https://github.com/kubernetes/kubernetes/issues/69699

Для того, чтобы logstash смог сформировать объект json-объект message нужно в конфигурацию прописать фильтр, который распарсит строку message , чтобы на выходе получился объект.
Встроенные паттерны тут: https://github.com/logstash-plugins/logstash-patterns-core/blob/master/patterns/grok-patterns
Проверить паттерны можно тут: http://grokdebug.herokuapp.com/
Для вышеприведенной стоки подходит такой фильтр:

%{SYSLOGTIMESTAMP:timestamp}%{SPACE}%{SYSLOGHOST:host}%{SPACE}%{SYSLOGPROG:process}:%{SPACE}%{GREEDYDATA:SYSLOGMESSAGE}

Для того, чтобы логи попадали в elasticsearch в конфиг rsyslog (/etc/rsyslog.conf) в конце надо дописать такое:

*.*  @@logstash.autosys.tk:1514

Тут *.* - это значит все записи, @@ - это TCP (@ - UDP), дальше хост logstash и порт.

logstash_values.yaml

---
replicas: 1

# Allows you to add any config files in /usr/share/logstash/config/
# such as logstash.yml and log4j2.properties
logstashConfig:
  logstash.yml: |
    http.host: "0.0.0.0"
    config.reload.automatic: "true"
    xpack.management.enabled: "false"
    
#    key:
#      nestedkey: value
#  log4j2.properties: |
#    key = value

# Allows you to add any pipeline files in /usr/share/logstash/pipeline/
logstashPipeline:
  input_main.conf: |
    input {
      udp {
        port => 1514
        type => syslog
      }
      tcp {
        port => 1514
        type => syslog
      }
      http {
        port => 8080
      }
      # kafka {
      #  ## ref: https://www.elastic.co/guide/en/logstash/current/plugins-inputs-kafka.html
      #   bootstrap_servers => "kafka-input:9092"
      #   codec => json { charset => "UTF-8" }
      #   consumer_threads => 1
      #   topics => ["source"]
      #   type => "example"
      # }
    }
  filter_main.conf: |
    filter {
      if [type] == "syslog" {
       # Uses built-in Grok patterns to parse this standard format
        grok {
          match => {
            "message" => "%{SYSLOGTIMESTAMP:@timestamp}%{SPACE}%{SYSLOGHOST:host}%{SPACE}%{SYSLOGPROG:process}:%{SPACE}%{GREEDYDATA:syslogmessage}"
          }
        }
        # Sets the timestamp of the event to the timestamp of recorded in the log-data
        # By default, logstash sets the timestamp to the time it was ingested.
        #date {
        #  match => [ "timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
        #}
        mutate {
          rename => ["syslogmessage", "message" ]
        }
      }
    }
  output_main.conf: |
    output {
     # stdout { codec => rubydebug }
      elasticsearch {
        hosts => ["${ELASTICSEARCH_HOST}:${ELASTICSEARCH_PORT}"]
        manage_template => false
        index => "logs-%{+YYYY.MM.dd}"
     }
     # kafka {
     #   ## ref: https://www.elastic.co/guide/en/logstash/current/plugins-outputs-kafka.html
     #   bootstrap_servers => "kafka-output:9092"
     #   codec => json { charset => "UTF-8" }
     #   compression_type => "lz4"
     #   topic_id => "destination"
     # }
    }

# Extra environment variables to append to this nodeGroup
# This will be appended to the current 'env:' key. You can use any of the kubernetes env
# syntax here
extraEnvs: 
  - name: "ELASTICSEARCH_HOST"
    value: "elasticsearch-master.elasticsearch.svc.cluster.local"
  - name: "ELASTICSEARCH_PORT"
    value: "9200"
#  - name: MY_ENVIRONMENT_VAR
#    value: the_value_goes_here

# A list of secrets and their paths to mount inside the pod
secretMounts: []

image: "docker.elastic.co/logstash/logstash"
imageTag: "7.5.1"
imagePullPolicy: "IfNotPresent"
imagePullSecrets: []

podAnnotations: {}

# additionals labels
labels:
  app: logstash
  
logstashJavaOpts: "-Xmx1g -Xms1g"

resources:
  requests:
    cpu: "100m"
    memory: "1536Mi"
  limits:
    cpu: "1000m"
    memory: "1536Mi"

volumeClaimTemplate:
  accessModes: [ "ReadWriteOnce" ]
  resources:
    requests:
      storage: 1Gi

rbac:
  create: false
  serviceAccountName: ""

podSecurityPolicy:
  create: false
  name: ""
  spec:
    privileged: true
    fsGroup:
      rule: RunAsAny
    runAsUser:
      rule: RunAsAny
    seLinux:
      rule: RunAsAny
    supplementalGroups:
      rule: RunAsAny
    volumes:
      - secret
      - configMap
      - persistentVolumeClaim

persistence:
  enabled: false
  annotations: {}

extraVolumes: ""
  # - name: extras
  #   emptyDir: {}

extraVolumeMounts: ""
  # - name: extras
  #   mountPath: /usr/share/extras
  #   readOnly: true

extraContainers: ""
  # - name: do-something
  #   image: busybox
  #   command: ['do', 'something']

extraInitContainers: ""
  # - name: do-something
  #   image: busybox
  #   command: ['do', 'something']

# This is the PriorityClass settings as defined in
# https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#priorityclass
priorityClassName: ""

# By default this will make sure two pods don't end up on the same node
# Changing this to a region would allow you to spread pods across regions
antiAffinityTopologyKey: "kubernetes.io/hostname"

# Hard means that by default pods will only be scheduled if there are enough nodes for them
# and that they will never end up on the same node. Setting this to soft will do this "best effort"
antiAffinity: "hard"

# This is the node affinity settings as defined in
# https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature
nodeAffinity: {}

# The default is to deploy all pods serially. By setting this to parallel all pods are started at
# the same time when bootstrapping the cluster
podManagementPolicy: "Parallel"

httpPort: 9600

updateStrategy: RollingUpdate

# This is the max unavailable setting for the pod disruption budget
# The default value of 1 will make sure that kubernetes won't allow more than 1
# of your pods to be unavailable during maintenance
maxUnavailable: 1

podSecurityContext:
  fsGroup: 1000
  runAsUser: 1000

securityContext:
  capabilities:
    drop:
    - ALL
  # readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 1000

# How long to wait for logstash to stop gracefully
terminationGracePeriod: 120

livenessProbe:
  httpGet:
    path: /
    port: http
  initialDelaySeconds: 300
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3
  successThreshold: 1

readinessProbe:
  httpGet:
    path: /
    port: http
  initialDelaySeconds: 60
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3
  successThreshold: 3

## Use an alternate scheduler.
## ref: https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/
##
schedulerName: ""

nodeSelector: {}
tolerations: []

nameOverride: ""
fullnameOverride: ""

lifecycle: {}
  # preStop:
  #   exec:
  #     command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
  # postStart:
  #   exec:
  #     command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]

service:
  annotations: {}
  type: LoadBalancer
  ports:
  - name: beats
    port: 5044
    protocol: TCP
    targetPort: 5044
  - name: http
    port: 8080
    protocol: TCP
    targetPort: 8080
  - name: syslog
    port: 1514
    targetPort: 1514

Create Persistent Volume for LogStash

sudo mkdir /kubernetes_volumes/logstash-data
sudo chmod a+rw -R /kubernetes_volumes/logstash-data

apiVersion: v1
kind: PersistentVolume
metadata:
   name: logstash-data
   namespace: elasticsearch
   labels:
     app: logstash
spec:
  capacity:
    storage: 2Gi
  accessModes:
  - ReadWriteOnce
  hostPath:
    path: "/kubernetes_volumes/logstash-data"
    type: Directory
  persistentVolumeReclaimPolicy: Retain

Проверка работоспособности ELK

Теперь можно проверить, что всё вместе работает.
Можно отправить сообщение в logstash на input http:

curl -XPUT 'http://~~~logstash~IP~~~:8080/test/test1/1' -d 'hello'

В ответ должно быть ok.
А в kibana можно нажать Discovery, увидеть там новый индекс.

Filebeat

Для работы с файлами логов потребуется дополнительный сервис Filebeat, который будет читать логи из файла и отправлять в Logstash. Пример конфигурации:

filebeat.inputs:
- type: log
  enabled: true
  paths:
      - /var/log/nginx/access.log
  fields:
    type: nginx
  fields_under_root: true
  scan_frequency: 5s

output.logstash:
  hosts: ["logstash:5000"]

Filebeat Autodiscover

У Filebeat есть отличный функцмонал - Autodiscover. Он позволяет по заданным правилам автоматически обнаруживать файлы с логами. Прмиер конфига для K8S:

filebeat:
  autodiscover:
    providers:
    - node: ${HOSTNAME}
      templates:
      - config:
        - containers:
            ids:
            - ${data.kubernetes.container.id}
          paths:
          - /var/log/containers/*-${data.kubernetes.container.id}.log
          type: container
      type: kubernetes
output:
  elasticsearch:
    hosts:
    - https://elk-es-http.elk.svc:9200
    password: 7hhjEqA6oH3049D1oTT9s4O2
    ssl:
      certificate_authorities:
      - /mnt/elastic-internal/elasticsearch-certs/ca.crt
    username: elk-elk-beat-user
processors:
- drop_fields:
    fields:
    - log
    - container.id
    - container.runtime
    - container.image.name
    - input.type
    - tags
    - kubernetes.labels
    - kubernetes.pod.uid
    - kubernetes.replicaset.name
    - kubernetes.node
    - kubernetes.namespace_labels
    - kubernetes.namespace_uid
    - ecs.version
    - agent
    ignore_missing: false
setup:
  dashboards:
    enabled: true
  kibana:
    host: http://elk-kb-http.elk.svc:5601
    password: 6l2IPFK8mBR88w6ek49ePI71
    username: elk-elk-beat-kb-user

Этот конфиг сформирован оператором ECK 1.8.
Что делать, если Filebeat Kubernetes Autodiscover не работает без видимых причин?? В моем случае - ошибок не было, но и логи контейнеров Filebeat Autodiscover не обнаруживал. Лог выглядел так:

...
2021-10-24T11:11:24.565Z        INFO    [autodiscover.pod]      kubernetes/util.go:122  kubernetes: Using node MCS-K8S-201 provided in the config
2021-10-24T11:11:24.565Z        DEBUG   [autodiscover.pod]      kubernetes/pod.go:80    Initializing a new Kubernetes watcher using node: MCS-K8S-201
2021-10-24T11:11:24.587Z        DEBUG   [autodiscover]  autodiscover/autodiscover.go:90 Configured autodiscover provider: kubernetes
2021-10-24T11:11:24.587Z        INFO    [autodiscover]  autodiscover/autodiscover.go:113        Starting autodiscover manager
2021-10-24T11:11:24.687Z        DEBUG   [kubernetes]    kubernetes/watcher.go:184       cache sync done
2021-10-24T11:11:24.788Z        DEBUG   [kubernetes]    kubernetes/watcher.go:184       cache sync done
2021-10-24T11:11:24.889Z        DEBUG   [kubernetes]    kubernetes/watcher.go:184       cache sync done
...

Однако, при нормальной работе - должно быть что-то такое:

...
2021-10-24T11:49:30.633Z        INFO    [autodiscover.pod]      kubernetes/util.go:122  kubernetes: Using node mcs-k8s-203 provided in the config
2021-10-24T11:49:30.642Z        INFO    [autodiscover]  autodiscover/autodiscover.go:113        Starting autodiscover manager
2021-10-24T11:49:31.048Z        INFO    [input] log/input.go:164        Configured paths: [/var/log/containers/*-70600db8d4371ebdacc300edd825c030e6698a6b75467ea8b280c7aef1faa366.log]  {"input_id": "f60ce837-5828-4125-afe5-5a40d70fc613"}
2021-10-24T11:49:31.048Z        INFO    [input] log/input.go:164        Configured paths: [/var/log/containers/*-70600db8d4371ebdacc300edd825c030e6698a6b75467ea8b280c7aef1faa366.log]  {"input_id": "ba234dcb-e0bd-4395-baa4-ba47dd1f1f6d"}
...

Я потратил довольно много времени на выяснение причин такого поведения. дело оказалось в том, что HOSTNAME на ноде задан большими буквами (MCS-K8S-203), а в кластере нода имеет имя маленькими буквами (mcs-k8s-203). В итоге - всё вылечилось, когда я на хостах кластера выполнил:

  sudo hostnamectl set-hostname `echo "$HOSTNAME" | tr '[:upper:]' '[:lower:]'`

то есть переменовал хосты кластера в нижнем регистре.

Настройка безопасности

По-умолчанию стек ELK не обеспечивает безопасного доступа к данным и компоненты никак не аутентифицируются. То есть записать и читать данные может кто угодно.
Базовая бесплатная лицензия не позволяет аутентифицировать пользователей из каталогов LDAP, поэтому нужно либо платить, либо настраивать аутентификацют сторонними методами.

LDAP-аутентификация в Kibana и RBAC для elasticsearch помощью oidc и proxy

Общая идея такая:

Пользователи имеют доступ только к kibana
Перед Kibana работает oidc-proxy (openresty), который осуществляет аутентификацию пользователя с помощью keycloak. Этот прокси добавляет в запросы, поступающие в kibana, заголовки, содержащие информацию о пользователе (в частности - список групп).
Kibana добавляет выбранные заголовки в запросы к elasticsearch.
Запросы от kibana к elasticsearch идет через второй proxy, который смотрит состав групп из заголовков и проксирует запросы только с разрешенными для данной группы URI и HTTP-методами.

Используемые компоненты:

Active Directory
Keycloak
openresty + lua-resty-openidc

Вот ссылочки, которые помогали мне в настройке oidc-proxy для LDAP-аутентификации :

Я изобретаю свои велосипеды, а вот есть некторые готовые компоненты:

образ openresty с oidc - https://github.com/flix-tech/openresty-oidc-proxy
вот решение для аутентификации elasticsearch в LDAP - https://mapr.com/blog/how-secure-elasticsearch-and-kibana/ - без использования OIDC, но там описана авторизация доступа к определенным URI и HTTP-методам с помощью lua, на основе имени пользователя (HTTP-заголовка) из реквеста. Я настраиваю более универсальный (но и более ресурсоемкий по причине перебора всех доступных групп) вариант с группами. Более экономичным может быть вариант с ролями. Для реализации ролей - их нужно настроить на keycloak. Роль, в сущности, это та же группа, однако, есть нюансы. LDAP-роль в keycloak дается на основании членства в группе. Роль может быть единственной (остальные, если есть, отбрасываются). Группы ролей, должны быть расположены в определенной OU.

Keycloak

Развернут с помощью helm - deploy_keycloak_using_helm.
REALM настроен так: https://habr.com/ru/post/441112/

Собираем образ openresty с модулем lua-resty-openidc

Dockerfile на базе https://github.com/Revomatico/docker-openresty-oidc/blob/master/Dockerfile :

FROM alpine:3.10
MAINTAINER Mikhail Usik <mike@autosys.tk>

ENV LUA_SUFFIX=jit-2.1.0-beta3 \
    LUAJIT_VERSION=2.1 \
    NGINX_PREFIX=/opt/openresty/nginx \
    OPENRESTY_PREFIX=/opt/openresty \
    OPENRESTY_SRC_SHA256=bf92af41d3ad22880047a8b283fc213d59c7c1b83f8dae82e50d14b64d73ac38 \
    OPENRESTY_VERSION=1.15.8.2 \
    LUAROCKS_VERSION=3.1.3 \
    LUAROCKS_SRC_SHA256=c573435f495aac159e34eaa0a3847172a2298eb6295fcdc35d565f9f9b990513 \
    LUA_RESTY_OPENIDC_VERSION=1.7.2-1 \
    VAR_PREFIX=/var/nginx

RUN set -ex \
  && apk --no-cache add \
    libgcc \
    libpcrecpp \
    libpcre16 \
    libpcre32 \
    libssl1.1 \
    libstdc++ \
    openssl \
    pcre \
    curl \
    unzip \
    git \
    dnsmasq \
    ca-certificates \
  && apk --no-cache add --virtual .build-dependencies \
    make \
    musl-dev \
    gcc \
    ncurses-dev \
    openssl-dev \
    pcre-dev \
    perl \
    readline-dev \
    zlib-dev \
    libc-dev \
  \
## OpenResty
  && curl -fsSL https://github.com/openresty/openresty/releases/download/v${OPENRESTY_VERSION}/openresty-${OPENRESTY_VERSION}.tar.gz -o /tmp/openresty.tar.gz \
  \
  && cd /tmp \
  && echo "${OPENRESTY_SRC_SHA256} *openresty.tar.gz" | sha256sum -c - \
  && tar -xzf openresty.tar.gz \
  \
  && cd openresty-* \
  && readonly NPROC=$(grep -c ^processor /proc/cpuinfo 2>/dev/null || 1) \
  && ./configure \
    --prefix=${OPENRESTY_PREFIX} \
    --http-client-body-temp-path=${VAR_PREFIX}/client_body_temp \
    --http-proxy-temp-path=${VAR_PREFIX}/proxy_temp \
    --http-log-path=${VAR_PREFIX}/access.log \
    --error-log-path=${VAR_PREFIX}/error.log \
    --pid-path=${VAR_PREFIX}/nginx.pid \
    --lock-path=${VAR_PREFIX}/nginx.lock \
    --with-luajit \
    --with-pcre-jit \
    --with-ipv6 \
    --with-http_ssl_module \
    --without-http_ssi_module \
    --with-http_realip_module \
    --without-http_scgi_module \
    --without-http_uwsgi_module \
    --without-http_userid_module \
    -j${NPROC} \
  && make -j${NPROC} \
  && make install \
  \
  && rm -rf /tmp/openresty* \
  \
## LuaRocks
  && curl -fsSL http://luarocks.github.io/luarocks/releases/luarocks-${LUAROCKS_VERSION}.tar.gz -o /tmp/luarocks.tar.gz \
  \
  && cd /tmp \
  && echo "${LUAROCKS_SRC_SHA256} *luarocks.tar.gz" | sha256sum -c - \
  && tar -xzf luarocks.tar.gz \
  \
  && cd luarocks-* \
  && ./configure \
    --prefix=${OPENRESTY_PREFIX}/luajit \
    --lua-suffix=${LUA_SUFFIX} \
    --with-lua=${OPENRESTY_PREFIX}/luajit \
    --with-lua-lib=${OPENRESTY_PREFIX}/luajit/lib \
    --with-lua-include=${OPENRESTY_PREFIX}/luajit/include/luajit-${LUAJIT_VERSION} \
  && make build \
  && make install \
  \
  && rm -rf /tmp/luarocks* \
  && rm -rf ~/.cache/luarocks \
## Post install
  && ln -sf ${NGINX_PREFIX}/sbin/nginx /usr/local/bin/nginx \
  && ln -sf ${NGINX_PREFIX}/sbin/nginx /usr/local/bin/openresty \
  && ln -sf ${OPENRESTY_PREFIX}/bin/resty /usr/local/bin/resty \
  && ln -sf ${OPENRESTY_PREFIX}/luajit/bin/luajit-* ${OPENRESTY_PREFIX}/luajit/bin/lua \
  && ln -sf ${OPENRESTY_PREFIX}/luajit/bin/luajit-* /usr/local/bin/lua  \
  && ln -sf ${OPENRESTY_PREFIX}/luajit/bin/luarocks /usr/local/bin/luarocks \
  && ln -sf ${OPENRESTY_PREFIX}/luajit/bin/luarocks-admin /usr/local/bin/luarocks-admin \
  && echo user=root >> /etc/dnsmasq.conf \
## Install lua-resty-openidc
  && cd ~/ \
  # Fix for https://github.com/zmartzone/lua-resty-openidc/issues/213#issuecomment-432471572
#  && luarocks install lua-resty-hmac \
  && luarocks install lua-resty-openidc ${LUA_RESTY_OPENIDC_VERSION} \
## Install lua-resty-xacml-pep
#  && curl -fsSL https://raw.githubusercontent.com/zmartzone/lua-resty-xacml-pep/master/lib/resty/xacml_pep.lua -o /opt/openresty/lualib/resty/xacml_pep.lua \
## Cleanup
  && apk del .build-dependencies 2>/dev/null

WORKDIR $NGINX_PREFIX

CMD dnsmasq; openresty -g "daemon off; error_log /dev/stderr info;"

ConfigMap для openresty

Создано по мотивам https://developers.redhat.com/blog/2018/10/08/configuring-nginx-keycloak-oauth-oidc/ и https://daenney.github.io/2019/10/05/beyondcorp-at-home-authn-authz-openresty

Описаны два виртуальных сервра (оба - прокси).

Первый - для аутентификации в kibana (аутентифицирует пользователя с помощью OIDC).
Второй - для авторизации запросов от kibana в elasticsearch. Проверяется содержимое заголовков (список групп пользователя) в запросах от Kibana и разрешения определенных методов при доступе к elasticsearch.

kind: ConfigMap
apiVersion: v1
metadata:
  name: openresty-oidc-config
  namespace: elasticsearch
data:
  nginx.conf: |
    worker_processes  1;
    events {
        worker_connections  1024;
    }
    http {
        include       mime.types;
        default_type  application/octet-stream;
        sendfile        on;
        keepalive_timeout  65;
        gzip  on;
        ##
        # LUA options
        ##
        lua_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
        lua_package_path '~/lua/?.lua;;';
        resolver 192.168.77.1;
        # cache for discovery metadata documents
        lua_shared_dict discovery 1m;
        # cache for JWKs
        lua_shared_dict jwks 1m;
        # allow the server to close connection on non responding client, this will free up memory
        reset_timedout_connection on;
    
        server {
        listen 80 default_server;
        server_name kibana.autosys.tk;
        #access_log /dev/stdout;
        #error_log /dev/stdout;
        access_by_lua '
          local opts = {
            redirect_uri = "/redirect_uri",
            accept_none_alg = true,
            discovery = "https://sso.autosys.tk/auth/realms/Autosys/.well-known/openid-configuration",
            client_id = "kibana",
            client_secret = "af903747-905c-4342-a62c-83033d3289cc",
            redirect_uri_scheme = "https",
            logout_path = "/logout",
            redirect_after_logout_uri = "https://sso.autosys.tk/auth/realms/Autosys/protocol/openid-connect/logout?redirect_uri=https://kibana.autosys.tk/",
            redirect_after_logout_with_id_token_hint = false,
            session_contents = {id_token=true}
          }
          -- call introspect for OAuth 2.0 Bearer Access Token validation
          local res, err = require("resty.openidc").authenticate(opts)
          if err then
            ngx.status = 403
            ngx.say(err)
            ngx.exit(ngx.HTTP_FORBIDDEN)
          end
          -- set data from the ID token as HTTP Request headers
          ngx.req.set_header("X-Auth-Username", res.id_token.preferred_username)
          ngx.req.set_header("X-Auth-Groups", res.id_token.groups)
          -- ngx.req.set_header("X-Auth-Audience", res.id_token.aud)
          -- ngx.req.set_header("X-Auth-Email", res.id_token.email)
          -- ngx.req.set_header("X-Auth-ExpiresIn", res.id_token.exp)
          -- ngx.req.set_header("X-Auth-Roles", res.id_token.roles)
          -- ngx.req.set_header("X-Auth-Name", res.id_token.name)
          -- ngx.req.set_header("X-Auth-Subject", res.id_token.sub)
          -- ngx.req.set_header("X-Auth-Userid", res.id_token.preferred_username)
          -- ngx.req.set_header("X-Auth-Locale", res.id_token.locale)
          -- Output headers to nginx err log
          --ngx.log(ngx.ERR, "Got header X-Auth-Userid: "..res.id_token.preferred_username..";")
        ';
        expires           0;
        add_header        Cache-Control private;
        location / {
          proxy_connect_timeout 5s;
          proxy_pass http://kibana-kibana.elasticsearch.svc.cluster.local:5601;
        }
      }
      server {
        listen 9200;
        access_log /dev/stdout;
        error_log /dev/stdout;
        access_by_lua '
        local restrictions = {
          elasticsearch_ro = {
            ["^/$"]                             = { "GET" },
            ["^/?[^/]*/?[^/]*/_mget"]           = { "GET", "POST" },
            ["^/?[^/]*/?[^/]*/_doc"]            = { "GET" },
            ["^/?[^/]*/?[^/]*/_search"]         = { "GET", "POST" },
            ["^/?[^/]*/?[^/]*/_msearch"]        = { "GET" },
            ["^/?[^/]*/?[^/]*/_validate/query"] = { "GET" },
            ["/_aliases"]                       = { "GET" },
            ["/_cluster.*"]                     = { "GET" }
          },
          elasticsearch_rw = {
            ["^/$"]                             = { "GET" },
            ["^/?[^/]*/?[^/]*/_search"]         = { "GET", "POST" },
            ["^/?[^/]*/?[^/]*/_msearch"]        = { "GET", "POST" },
            ["^/?[^/]*/traffic*"]               = { "GET", "POST", "PUT", "DELETE" },
            ["^/?[^/]*/?[^/]*/_validate/query"] = { "GET", "POST" },
            ["/_aliases"]                       = { "GET" },
            ["/_cluster.*"]                     = { "GET" }
          },
          elasticsearch_full = {
            ["^/?[^/]*/?[^/]*/_bulk"]          = { "GET", "POST" },
            ["^/?[^/]*/?[^/]*/_refresh"]       = { "GET", "POST" },
            ["^/?[^/]*/?[^/]*/?[^/]*/_create"] = { "GET", "POST" },
            ["^/?[^/]*/?[^/]*/?[^/]*/_update"] = { "GET", "POST" },
            ["^/?[^/]*/?[^/]*/?.*"]            = { "GET", "POST", "PUT", "DELETE" },
            ["^/?[^/]*/?[^/]*$"]               = { "GET", "POST", "PUT", "DELETE" },
            ["/_aliases"]                      = { "GET", "POST" }
          }
        }
        local groups = ngx.req.get_headers()["x-auth-groups"]
        local authenticated_group = nil
        local ngx_re = require "ngx.re"
        if ( type(groups) == "string" and string.len(groups) >= 1 ) then
          groups = string.lower(groups)
          ngx.log(ngx.ERR, "Got header X-Auth-Groups: "..groups..";")
          local groups_table = ngx_re.split(groups, ", ")
          local groups_number = table.getn(groups_table)
          ngx.log(ngx.ERR, "Groups number : "..groups_number..";")
          for i=1,groups_number do
            local group = groups_table[i]:gsub("/","")
            group = group:gsub("%s","_")
            ngx.log(ngx.ERR, "Check group: "..group..";")
            if (restrictions[group] ~= nil) then
              ngx.log(ngx.ERR, "User belongs to Authenticated Group: "..group..";")
              authenticated_group = group
              break
            end
          end
          -- exit 403 when no matching role has been found
          if authenticated_group == nil then
            ngx.header.content_type = "text/plain"
            ngx.log(ngx.ERR, "Unauthenticated request... User - "..ngx.req.get_headers()["x-auth-username"]..";")
            ngx.status = 403
            ngx.say("403 Forbidden: You don\'t have access to this resource.")
            return ngx.exit(403)
          end
          
          -- get URL
          local uri = ngx.var.uri
          ngx.log(ngx.DEBUG, uri)
          -- get method
          local method = ngx.req.get_method()
          ngx.log(ngx.DEBUG, method)
          
          local allowed  = false
          
          for path, methods in pairs(restrictions[authenticated_group]) do
          
            -- path matched rules?
            local p = string.match(uri, path)
            
            local m = nil
            
            -- method matched rules?
            for _, _method in pairs(methods) do
              m = m and m or string.match(method, _method)
            end
            
            if p and m then
              allowed = true
              ngx.log(ngx.NOTICE, method.." "..uri.." matched: "..tostring(m).." "..tostring(path).." for "..authenticated_group)
              break
            end
          end

          if not allowed then
            ngx.header.content_type = "text/plain"
            ngx.log(ngx.WARN, "Group ["..authenticated_group.."] not allowed to access the resource ["..method.." "..uri.."]")
            ngx.status = 403
            ngx.say("403 Forbidden: You don\'t have access to this resource.")
            return ngx.exit(403)
          end
        end
        ';
        location / {
          proxy_connect_timeout 15s;
          proxy_pass http://elasticsearch-master.elasticsearch.svc.cluster.local:9200;
        }
      }
    }

В конфигурации первого прокси аутентификацию выполняет блок access_by_lua. В local opts прописано следующее:

redirect_uri - всегда будет “/redirect_uri”
discovery - ссылка с конфигурацией реалма. Обычно нужно заменить адрес хоста keycloak и имя реалма.
client_id - задается в keycloak при создании клиента.
client_secret - генерируется в keycloak
redirect_uri_scheme - http или https
logout_path - всегда будет “/logout”

В конфигурации второго прокси авторизацию также выполняет блок access_by_lua:

В блоке local restrictions = { содержится список таблиц (с именами групп), а в таблицах - список uri и методов разрешенных членам группы для этих uri. Имена групп в LDAP могут включать в себя пробелы и большие буквы (при проверке имена групп из LDAP будут приведены к нижнему регистру, а пробелы будут преобразованы в символ подчеркивания).
В данном алгоритме группы, которые нашлись в заголовке x-auth-groups проверяются по порядку. Если нашлось совпадение имени группы из заголовка x-auth-groups с именем таблицы из local restrictions, то пользователю будут даны права в соотвествии с первой найденной группой.

openresty-oidc_deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:    
  name: openresty-oidc
  namespace: elasticsearch
spec:
  replicas: 1
  selector:  
    matchLabels:
      app: openresty-oidc
  template:  
    metadata:
      labels:
        app: openresty-oidc
    spec:
      imagePullSecrets:
      - name: autosys-regcred    
      containers:    
        - name: openresty-oidc
          image: registry.autosys.tk/openresty-oidc
          volumeMounts:
            - name: openresty-oidc-config-volume
              mountPath: /opt/openresty/nginx/conf/nginx.conf
              subPath: nginx.conf
      volumes:
        - name: openresty-oidc-config-volume
          configMap:
            name: openresty-oidc-config

openresty-oidc-service

apiVersion: v1
kind: Service
metadata:
  name: openresty-oidc-http
  namespace: elasticsearch
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  - name: elasticsearch
    port: 9200
    protocol: TCP
    targetPort: 9200
  selector:
    app: openresty-oidc
  sessionAffinity: None
  type: ClusterIP

kibana-values.yaml

В конфигурации kibana нужно внести следующие изменения с помощью helm upgrade:

Включить elasticsearch.requestHeadersWhitelist, чтобы kibana добавляла в свои запросы к elasticsearch заголовки с группами пользователя.
Указать в качестве elasticsearchHosts адрес авторизующего proxy.

elasticsearchHosts: "http://openresty-oidc-http.elasticsearch.svc.cluster.local:9200"
kibanaConfig:
  kibana.yml: |
    server.name: kibana
    server.host: "0"
    xpack.monitoring.ui.container.elasticsearch.enabled: true
    elasticsearch.requestHeadersWhitelist:
    - authorization
    - x-auth-groups
    - x-auth-username

kibana-ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
    kubernetes.io/ingress.class: nginx
  name: kibana-ingress
  namespace: elasticsearch
spec:
  rules:
  - host: kibana.autosys.tk
    http:
      paths:
      - backend:
          serviceName: openresty-oidc-http
          servicePort: 80
        path: /
  tls:
  - hosts:
    - kibana.autosys.tk
    secretName: kibana-autosys-tk-tls

RBAC using Oidc proxy

С одной стороны - можно продолжать наполнять таблицу привилегий OIDC-proxy. Недостатки - большая и сложная таблица, медленная работа.
C другой стороны - в коде OIDC-proxy средствами ES API можно реализовать механизм проверки наличия пользователя в базе ES, создания ее в случае отсутствия, а также назначения ролей встроенных в ES, в соответствии с группами.

API - https://www.elastic.co/guide/en/elasticsearch/reference/current/rest-apis.html
ROles - https://www.elastic.co/guide/en/elasticsearch/reference/current/built-in-roles.html

API	RO	RW	FULL
/_cluster	GET	GET	GET PUT POST DELETE
/_cat	GET	GET	GET
/_nodes	GET	GET	GET POST
/_remote	GET	GET	GET
/_tasks	GET	GET	GET
/_ccr	GET	GET	GET
*	GET	GET	GET	PUT

Разные проблемы

Произвольная деаутентификация клиента openresty oidc proxy

Меня зачпокала ситуация, когда вроде всё работает, но в любой момент в логе nginx oidc-proxy может появиться ошибка

2020/04/07 18:46:22 [alert] 12#0: *12 ignoring stale global SSL error (SSL: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt) while SSL handshaking to upstream, client: 10.244.0.71, server: kibanadomain.local, request: "GET /built_assets/css/plugins/ml/application/index.light.css HTTP/1.1", upstream: "https://10.104.117.4:5601/built_assets/css/plugins/ml/application/index.light.css", host: "kibana.domain.local", referrer: "https://kibana.domain.local/app/kibana

и дальше cookie сессии сбрасываются, клиент деаутетифицируется и последующие запросы уже идут с кодом 302 и редиректом на redirect_uri.

Причина

Причина и решение описаны тут: https://github.com/bungle/lua-resty-session/issues/23
Судя по всему - причина кроется в механизмах шифрования-расшифровывания. А именно - в сессионном ключе. Если явно не задано значение переменной $session_secret, то каждый worker сгенерирует свой собственный секрет и они не смогут расшифровать данные зашифрованные разными ключами. Поэтому - глюк плавающий. Он повторяется рандомно.
Решение - либо добавить в секцию server значение $session_secret длинной 32 байта:

server {
    ...
    set $session_secret T62DGscdGyb4So4tLsXhNIRdlEpt4J2k;

либо использовать единственный worker.

Elasticsearch operator и OSS docker images

При попытке использовать имиджи Elasticsearch OSS 7.6.2, для разворачивания кластера средствами elasticsearch operator все поды всегда уходили в бесконечный InitError.

Диагностика

Смотрим describe любого пода и видим:

Events:
  Type     Reason     Age                From                       Message
  ----     ------     ----               ----                       -------
  Normal   Scheduled  44s                default-scheduler          Successfully assigned default/elasticsearch-es-master-2 to kub-dev-master01
  Normal   Pulled     22s (x3 over 41s)  kubelet, kub-dev-master01  Container image "registry.rdleas.ru:5000/elasticsearch/elasticsearch-oss:7.6.2" already present on machine
  Normal   Created    21s (x3 over 40s)  kubelet, kub-dev-master01  Created container elastic-internal-init-filesystem
  Normal   Started    21s (x3 over 40s)  kubelet, kub-dev-master01  Started container elastic-internal-init-filesystem
  Warning  BackOff    7s (x5 over 36s)   kubelet, kub-dev-master01  Back-off restarting failed container

Смотрим логи контейнера elastic-internal-init-filesystem и видим:

$ kubectl logs elasticsearch-es-master-0 -c elastic-internal-init-filesystem
unsupported_distribution

Легкое гугление приводит нас сюда: https://github.com/sebgl/cloud-on-k8s/commit/c1a88cee00bc583dc28217747d4a39160904f013 , где написано, что OSS имиджи не поддерживаются оператором:

The operator only works with the official ES distributions to enable the security
available with the basic (free), gold and platinum licenses in order to ensure that
all clusters launched are secured by default.

A check is done in the prepare-fs script by looking at the existence of the
Elastic License. If not present, the script exit with a custom exit code.

Then the ES reconcilation loop sends an event of type warning if it detects that
a prepare-fs init container terminated with this exit code.

Ошибки SSL

Кластер развернут с помощью elasticsearch operator 1.0.1.

$ kubectl exec -it elasticsearch-es-master-0 -- bin/elasticsearch-setup-passwords interactive
19:52:29.467 [main] WARN  org.elasticsearch.common.ssl.DiagnosticTrustManager - failed to establish trust with server at [10.244.0.210]; the server provided a certificate with subject name [CN=elasticsearch-es-http.default.es.local,OU=elasticsearch] and fingerprint [74c38cee7c20e080613da16e86c9d5570d238717]; the certificate has subject alternative names [DNS:elasticsearch-es-http.default.es.local,DNS:elasticsearch-es-http,DNS:elasticsearch-es-http.default.svc,DNS:elasticsearch-es-http.default]; the certificate is issued by [CN=elasticsearch-http,OU=elasticsearch]; the certificate is signed by (subject [CN=elasticsearch-http,OU=elasticsearch] fingerprint [5d410bb81a7da9148cf71156ee07e36fa85ee5ef] {trusted issuer}) which is self-issued; the [CN=elasticsearch-http,OU=elasticsearch] certificate is trusted in this ssl context ([xpack.security.http.ssl])
java.security.cert.CertificateException: No subject alternative names matching IP address 10.244.0.210 found
....
....
....
SSL connection to https://10.244.0.210:9200/_security/_authenticate?pretty failed: No subject alternative names matching IP address 10.244.0.210 found
Please check the elasticsearch SSL settings under xpack.security.http.ssl.

ERROR: Failed to establish SSL connection to elasticsearch at https://10.244.0.210:9200/_security/_authenticate?pretty. 
command terminated with exit code 78

В кластере единственный master. При попытке подключения утилита обращается по IP-адресу, а не по имени. Видно, что сертификат у сервера есть.
Как написано тут: https://www.elastic.co/guide/en/elasticsearch/reference/master/trb-security-setup.html достаточно привести конфиг к такому виду:

  xpack.security.enabled: true
  xpack.security.http.ssl.verification_mode: certificate

Ошибка при начальной смене паролей bin/elasticsearch-setup-passwords

При выполнении команды bin/elasticsearch-setup-passwords появляется ошибка :

$ kubectl exec -it elasticsearch-es-master-0 -- bin/elasticsearch-setup-passwords auto
Failed to authenticate user 'elastic' against https://10.244.0.219:9200/_security/_authenticate?pretty
Possible causes include:
 * The password for the 'elastic' user has already been changed on this cluster
 * Your elasticsearch node is running against a different keystore
   This tool used the keystore at /usr/share/elasticsearch/config/elasticsearch.keystore

Это значит, что пароли встроенных учеток уже заданы elasticsearch operator в процессе установки elasticsearch, они хранятся в секретах elasticsearch-es-internal-users и elasticsearch-es-elastic-user:

kubectl get secrets elasticsearch-es-internal-users -o=jsonpath='{.data.elastic-internal}' | base64 --decode

kubectl get secret elasticsearch-es-elastic-user -o=jsonpath='{.data.elastic}' | base64 --decode

Если на перед создание экземпляра кластера elasticsearch создать секреты elasticsearch-es-internal-users и elasticsearch-es-elastic-user, то встроенным учетным записям будут назначены указанные там пароли. Это написано тут (там же написано как заскриптовать смену пароля): https://github.com/elastic/cloud-on-k8s/issues/967
А вообще - в ближайшее время elasticsearch operator позволит задавать пароли для встроенных учеток прямо в конфиге: https://github.com/elastic/cloud-on-k8s/pull/2682

deploy_jupyterhub_on_kubernetes

anonymous@undisclosed.example.com (Anonymous) — Fri, 17 Jan 2020 07:44:27 +0000

JupyterHub

JupyterHub - решение для многопользовательских сред.

HTTP-proxy, осуществляющий маршрутизацию запросов пользователей
HUB, который осуществляет аутентификацию пользователей (с помощью Authenticator) и управление индивидуальными jupyter-notebook (с помощью Spawners)

При входе пользователя для него создается Pod (с именем jupyter-username), в котором и будет работать пользователь. Для этого pod'а создается PersistentVolumeClaim, соотвественно нужен PersistentVolume.

https://z2jh.jupyter.org/en/latest/setup-jupyterhub/setup-jupyterhub.html
https://hub.docker.com/r/jupyterhub/k8s-hub/tags
https://zero-to-jupyterhub.readthedocs.io/en/latest/administrator/authentication.html
https://ipython-books.github.io/36-introducing-jupyterlab/

kubectl create ns jhub
helm repo add jupyterhub https://jupyterhub.github.io/helm-chart/
helm repo update
echo -e "proxy:\n  secretToken: '`openssl rand -hex 32`'" > ./jhub_config.yaml
helm upgrade --install jhub jupyterhub/jupyterhub --namespace jhub --version=0.9.0-beta.2 --values jhub_config.yaml

jhub_pvs.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: hub-db-dir-pv
  namespace: jhub
  labels:
    app: jupyterhub
    component: hub
spec:
  capacity:
    storage: 20Gi
  accessModes:
  - ReadWriteOnce
  hostPath:
    path: "/kubernetes_volumes/jhub/hub-db-dir-pv"
    type: Directory
  persistentVolumeReclaimPolicy: Retain
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: jhub-admin-pv
  namespace: jhub 
  labels:
    app: jupyterhub
    component: singleuser-server
spec:
  capacity:
    storage: 20Gi
  accessModes:   
  - ReadWriteOnce
  hostPath:
    path: "/kubernetes_volumes/jhub/jhub-admin-pv"
    type: Directory
  persistentVolumeReclaimPolicy: Retain

Ошибки текущей стабильной версии 0.8.2

Exception in Future <Task finished coro=<BaseHandler.spawn_single_user.<locals>.finish_user_spawn() done, defined at /usr/local/lib/python3.6/dist-packages/jupyterhub/handlers/base.py:629> exception=TypeError("'<' not supported between instances of 'datetime.datetime' and 'NoneType'",)> after timeout

Такая ошибка возникает, если запускать версию 0.8.2 в кластере kubernetes версии выше, чем 0.14. Решение для версии 0.8.2 можно найти тут: https://github.com/jupyterhub/kubespawner/issues/354
Либо можно обновить jhub до более новой версии :

 helm upgrade jhub jupyterhub/jupyterhub --namespace jhub --version=0.9.0-beta.2

Jupyter Notebook on kubernetes

Как выбрать подходящий docker-image: https://jupyter-docker-stacks.readthedocs.io/en/latest/using/selecting.html
Я буду разворачивать jupyter/scipy-notebook.

jupyter_deployment.yaml

kind: Namespace
apiVersion: v1
metadata:
  name: jupyter-notebook
  labels:
    name: jupyter-notebook
---
apiVersion: apps/v1
kind: Deployment
metadata:    
  name: jupyter-notebook
  namespace: jupyter-notebook
spec:
  replicas: 1
  selector:  
    matchLabels:
      app: jupyter-notebook
  template:  
    metadata:
      labels:
        app: jupyter-notebook
    spec:
      containers:    
        - name: jupyter-notebook
          image: jupyter/scipy-notebook:latest
---
apiVersion: v1
kind: Service
metadata:
  name: jupyter-notebook-http
  namespace: jupyter-notebook
spec:
  selector: 
    app: jupyter-notebook
  type: ClusterIP
  ports:
  - name: http
    port: 8888
    protocol: TCP
    targetPort: 8888
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: letsencrypt
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
  name: jupyter-notebook-ingress
  namespace: jupyter-notebook
spec:
  rules:
  - host: jpn.autosys.tk
    http:
      paths:
      - backend:
          serviceName: jupyter-notebook-http
          servicePort: 8888
        path: /
  tls:
  - hosts:
    - jpn.autosys.tk
    secretName:  jpn-autosys-tk-tls

Книжка по JuPyter Notebook

https://ipython-books.github.io/
https://github.com/ipython-books/cookbook-2nd

deploy_keycloak_using_helm

anonymous@undisclosed.example.com (Anonymous) — Wed, 10 Jun 2020 18:59:20 +0000

Установка keycloak с помощью helm-чарта

Клонируем репозиторий с чартом:

mkdir ~/keycloak && cd ~/keycloak
git clone https://github.com/codecentric/helm-charts.git
echo '' > helm-charts/charts/keycloak/requirements.yaml

Cоздание базы на сервере postgres

user@postgres:~$ sudo su - postgres
postgres@postgres:~$ psql

postgres=# create database keycloak;
CREATE DATABASE
postgres=# create user keycloak with encrypted password 'keycloak_db_password';
CREATE ROLE
postgres=# grant all privileges on database keycloak to keycloak;
GRANT

Создание неймспейса и секретов (паролей и сертов)

Создаем неймспейс

kubectl create ns keycloak

Создаем секреты с дефолтным паролем админской учетки keycloak и паролем пользователя базы данных:

kubectl create secret generic keycloak-default-admin-password -n keycloak --from-literal=password=keycloak_console_password 
kubectl create secret generic keycloak-db-password -n keycloak --from-literal=password=keycloak_db_password --from-literal=username=keycloak

Создаем секрет с ssl-сертификатом web-интерфейса:

openssl pkcs12 -in sso.domain.local.pfx -nocerts -out sso.domain.local.key
openssl rsa -in sso.domain.local.key -out sso.domain.local.key.pem
openssl pkcs12 -in sso.domain.local.pfx -clcerts -nokeys -out sso.domain.local.cert.crt
kubectl create secret generic -n keycloak sso-domain-local --from-file=tls.crt=./sso.domain.local.cert.crt --from-file=tls.key=./sso.domain.local.key.pem

Создаем ConfigMap с корпоративными корневыми сертификатами. Они должны быть в формате pem и оформлены стандартными разделителями - —–BEGIN CERTIFICATE—– и —–END CERTIFICATE—–.

kubectl -n keycloak create configmap ca-bundle --from-file=./ca.cer

keycloak_values.yaml

keycloak:
  replicas: 1
  image:
    tag: 8.0.2
  existingSecret: "keycloak-default-admin-password"

  extraVolumes: |
    - name: ca-bundle
      configMap:
        name: ca-bundle
  extraVolumeMounts: |
    - name: ca-bundle
      mountPath: /custom_certs/

  extraEnv: |
    - name: X509_CA_BUNDLE
      value: "/custom_certs/ca.cer"
    - name:  PROXY_ADDRESS_FORWARDING
      value: "true"
    - name: JAVA_OPTS
      value: |
        -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dkeycloak.profile.feature.upload_scripts=enabled

  ingress:
    enabled: true
    path: /
    annotations: 
      kubernetes.io/ingress.class: nginx
    hosts:
      - sso.domain.local
    tls:
      - hosts:
        - sso.domain.local
        secretName: sso-domain-local

  persistence:
    deployPostgres: false
    dbVendor: "postgres"
    existingSecret: "keycloak-db-password"
    dbName: keycloak
    dbHost: 10.10.10.10
    dbPort: 5432

test:
  enabled: false

Созданный ConfigMap с корпоративными корневыми сертификатами монтируется в директорию /custom_certs/.
Переменная X509_CA_BUNDLE указывает на путь к файлу с сертификатами и при старте контейнера используется скриптом /opt/jboss/tools/x509.sh, который импортирует сертификаты из файла в keystore.
Переменная PROXY_ADDRESS_FORWARDING нужна для нормального проксирования заголовков X-Forwarded-For. Если ёе не задать, то при попытке открыть Keycloak Administration Console можно будет увидеть лишь пустую страницу.
Переменная JAVA_OPTS переопределяется для того, чтобы добавить -Dkeycloak.profile.feature.upload_scripts=enabled. Это нужно для того, чтобы нормально работал импорт ранее забекапленных (экспортированных) реалмов. Без этого параметра, при попытке импорта ранее экспортированного реалма в логах будет ошибка:
```
keycloak Uncaught server error: java.lang.RuntimeException: Script upload is disabled
```

Ошибки при обновлении

При обновлении с версии 8.0.2 до версии 9.0.3 в логах возникла ошибка:

16:11:15,512 INFO  [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (ServerService Thread Pool -- 68) Updating database. Using changelog META-INF/jpa-changelog-master.xml
16:11:15,595 ERROR [org.keycloak.connections.jpa.updater.liquibase.conn.DefaultLiquibaseConnectionProvider] (ServerService Thread Pool -- 68) Change Set META-INF/jpa-changelog-9.0.1.xml::9.0.1-KEYCLOAK-12579-add-not-null-constraint::keycloak failed.  Error: ERROR: duplicate key value violates unique constraint "sibling_names"
  Detail: Key (realm_id, parent_group, name)=(rdleas,  , 1_SrvDocs_DocumentationAIB_Owner) already exists. [Failed SQL: UPDATE public.KEYCLOAK_GROUP SET PARENT_GROUP = ' ' WHERE PARENT_GROUP IS NULL]
16:11:15,602 FATAL [org.keycloak.services] (ServerService Thread Pool -- 68) java.lang.RuntimeException: Failed to update database

Судя по всему - в базе две записи о группе 1_SrvDocs_DocumentationAIB_Owner.
Сначала - останавливаем keycloak. для этого редактируем statefullSet и ставим replicas: 0
Идем на сервер postgres, перевоплощаемся в пользователя postgres:

sudo su - postgres

и лечим. Для начала - восстановим базу из бекапа в исходное состояние:

dropdb keycloak
createdb keycloak
psql -d keycloak -f ./keycloak_10.06.20_15-03.bak

Дальше запускаем psql и смотрим список баз:

\l

Переключаемся на базу keycloak:

\c keycloak

Убеждаемся, что записей о группе две:

SELECT * FROM public.KEYCLOAK_GROUP WHERE name = '1_SrvDocs_DocumentationAIB_Owner';

Непонятно, какая из них правильная - удаляем обе:

DELETE FROM public.KEYCLOAK_GROUP WHERE name = '1_SrvDocs_DocumentationAIB_Owner';

Приложение для тестирования KeyCloak (python Flask)

Протестировать keycloak и убедиться, что он настроен правильно и работает можно с помощью простых приложений.

flask_oidc

https://gist.github.com/thomasdarimont/145dc9aa857b831ff2eff221b79d179a (https://gist.githubusercontent.com/thomasdarimont/145dc9aa857b831ff2eff221b79d179a/raw/a72a9462b2bd693913efba86cbc74f87c043121d/app.py)
https://gist.githubusercontent.com/thomasdarimont/145dc9aa857b831ff2eff221b79d179a/raw/a72a9462b2bd693913efba86cbc74f87c043121d/client_secrets.json
Ставим то что нужно:

sudo pip3 --trusted-host pypi.org --trusted-host files.pythonhosted.org --proxy=http://127.0.0.1:3130 install flask flask_oidc cherrypy cryptojwt cryptography>=2.8

Тестовое приложение на фреймворке flask - app.py.

#!/usr/bin/env python3
import json
import logging

from flask import Flask, g
from flask_oidc import OpenIDConnect
import requests

logging.basicConfig(level=logging.DEBUG)

app = Flask(__name__)
app.config.update({
    'SECRET_KEY': 'SomethingNotEntirelySecret',
    'TESTING': True,
    'DEBUG': True,
    'OIDC_CLIENT_SECRETS': 'client_secrets.json',
    'OIDC_ID_TOKEN_COOKIE_SECURE': False,
    'OIDC_REQUIRE_VERIFIED_EMAIL': False,
    'OIDC_USER_INFO_ENABLED': True,
    'OIDC_OPENID_REALM': 'flask-demo',
    'OIDC_SCOPES': ['openid', 'email', 'profile'],
    'OIDC_INTROSPECTION_AUTH_METHOD': 'client_secret_post'
})

oidc = OpenIDConnect(app)

@app.route('/')
def hello_world():
    if oidc.user_loggedin:
        return ('Hello, %s, <a href="/private">See private</a> '
                '<a href="/logout">Log out</a>') % \
            oidc.user_getfield('preferred_username')
    else:
        return 'Welcome anonymous, <a href="/private">Log in</a>'

@app.route('/private')
@oidc.require_login
def hello_me():
    """Example for protected endpoint that extracts private information from the OpenID Connect id_token.
       Uses the accompanied access_token to access a backend service.
    """

    info = oidc.user_getinfo(['preferred_username', 'email', 'sub', 'groups'])

    username = info.get('preferred_username')
    email = info.get('email')
    user_id = info.get('sub')
    groups = info.get('groups')
    greeting = 'Greeting!!!'
    """if user_id in oidc.credentials_store:
        try:
            from oauth2client.client import OAuth2Credentials
            access_token = OAuth2Credentials.from_json(oidc.credentials_store[user_id]).access_token
            print ('access_token=<%s>' % access_token)
            headers = {'Authorization': 'Bearer %s' % (access_token)}
            # YOLO
            # greeting = requests.get('http://localhost:8080/greeting', headers=headers).text
        except:
            print ("Could not access greeting-service")
            greeting = "Hello %s" % username
"""
    return (""" %s </br>
               Your email is %s </br>
               Your user_id is %s! </br>
               Your Groups - %s </br>
               <ul>
                 <li><a href="/">Home</a></li>
                 <li><a href="https://sso.rdleas.ru/auth/realms/rdleas/account?referrer=flask-app&referrer_uri=http://192.168.104.94:5000/private&">Account</a></li>
                </ul>""" %
            (greeting, email, user_id, groups))

@app.route('/api', methods=['POST'])
@oidc.accept_token(require_token=True, scopes_required=['openid'])
def hello_api():
    """OAuth 2.0 protected API endpoint accessible via AccessToken"""

    return json.dumps({'hello': 'Welcome %s' % g.oidc_token_info['sub']})

@app.route('/logout')
def logout():
    """Performs local logout by removing the session cookie."""

    oidc.logout()
    return 'Hi, you have been logged out! <a href="/">Return</a>'

if __name__ == '__main__':
     app.run(host= '0.0.0.0')
#    app.run()

И конфигурационный файл для него - client_secrets.json

{
    "web": {
        "issuer": "https://sso.rdleas.ru/auth/realms/rdleas",
        "auth_uri": "https://sso.rdleas.ru/auth/realms/rdleas/protocol/openid-connect/auth",
        "client_id": "test",
        "client_secret": "32e8263a-9edc-4159-902a-e23c22606b1d",
        "redirect_uris": [
            "http://192.168.104.94:5000/*"
        ],
        "userinfo_uri": "https://sso.rdleas.ru/auth/realms/rdleas/protocol/openid-connect/userinfo",
        "token_uri": "https://sso.rdleas.ru/auth/realms/rdleas/protocol/openid-connect/token",
        "token_introspection_uri": "https://sso.rdleas.ru/auth/realms/rdleas/protocol/openid-connect/token/introspect"
    }
}

Запускаем так:

./app.py

JWTConnect-Python-OidcRP

Вот еще один ваиант тестового приложения. Но его запуск я не осилил.

git clone https://github.com/openid/JWTConnect-Python-OidcRP.git
cd ./JWTConnect-Python-OidcRP/chrp
cp ./example_conf.py ./conf.py
./make_opbyuid_html.py conf > html/opbyuid.html
sudo pip3 --trusted-host pypi.org --trusted-host files.pythonhosted.org --proxy=http://127.0.0.1:3130 install cherrypy cryptojwt cryptography>=2.8

deploy_nexus_on_kubernetes

anonymous@undisclosed.example.com (Anonymous) — Fri, 20 Mar 2020 13:59:34 +0000

Задача

Нужно развернуть Nexus Repository 3 внутри кластера Kubernetes.
В кластере настроен LoadBalancer и CertManager.
Образ Docker есть на hub.docker.com.

Nexus Namespace

kubectl create ns nexus

Nexus StorageClass PersistentVolumeClaim PersistentVolume

Для работы Nexus нужна директория. где он будет хранить артефакты. Для этого создаим StorageClass, PersistentVolumeСlaim и сам PersistentVolume:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nexus-storage-class
  namespace: nexus
provisioner: kubernetes.io/no-provisioner
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nexus-data-pv-claim
  namespace: nexus
spec:
  storageClassName: nexus-storage-class
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  selector:
    matchLabels:
      app: nexus-server
---
apiVersion: v1
kind: PersistentVolume
metadata:
   name: nexus-data-pv
   namespace: nexus
   labels:
     app: nexus-server
spec:
  capacity:
    storage: 20Gi
  accessModes:
  - ReadWriteOnce
  storageClassName: nexus-storage-class
  hostPath:
    path: "/kubernetes_volumes/nexus-data"
    type: Directory
  persistentVolumeReclaimPolicy: Retain

Nexus deployment

apiVersion: apps/v1
kind: Deployment
metadata:    
  name: nexus
  namespace: nexus
spec:
  replicas: 1
  selector:  
    matchLabels:
      app: nexus-server
  template:  
    metadata:
      labels:
        app: nexus-server
    spec:
      containers:    
        - name: nexus
          image: sonatype/nexus3:latest
          resources:
            limits:
              memory: "4Gi"
              cpu: "1000m"
            requests:
              memory: "1Gi"
              cpu: "500m"
          ports:
            - containerPort: 8081
          volumeMounts:
            - name: nexus-data
              mountPath: /nexus-data
      volumes:
      - name: nexus-data
        persistentVolumeClaim:
          claimName: nexus-data-pv-claim

Nexus Service and Ingress

apiVersion: v1
kind: Service
metadata:
  name: nexus-svc
  namespace: nexus
  annotations:
      prometheus.io/scrape: 'true'
      prometheus.io/path:   /
      prometheus.io/port:   '8081'
spec:
  selector: 
    app: nexus-server
  type: ClusterIP
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8081
  - name: docker-registry
    port: 5000
    protocol: TCP
    targetPort: 5000
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: letsencrypt
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
    nginx.ingress.kubernetes.io/client-max-body-size: "4096m"
  name: nexus-ingress
  namespace: nexus
spec:
  rules:
  - host: nexus.domain.com
    http:
      paths:
      - backend:
          serviceName: nexus-svc
          servicePort: 80
        path: /
  tls:
  - hosts:
    - nexus.domain.com
    secretName:  nexus-domain-com-tls
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: letsencrypt
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
    nginx.ingress.kubernetes.io/client-max-body-size: "4096m"
  name: nexus-docker-ingress
  namespace: nexus
spec:
  rules:
  - host: registry.autosys.tk
    http:
      paths:
      - backend:
          serviceName: nexus-svc
          servicePort: 5000
        path: /
  tls:
  - hosts:
    - registry.autosys.tk
    secretName:  registry-autosys-tk-tls

Дефолтный пароль admin

Администативная учетка - admin.
Пароль по-умолчанию от учетки admin генерируется во время deplyment'а и хранится в корневой папке PersistentVolume - в файле admin.password.

deploy_prometheus_on_kubernetes_using_prometheus-operator

anonymous@undisclosed.example.com (Anonymous) — Thu, 17 Sep 2020 06:54:39 +0000

Installing

kubectl create ns monitoring
helm install --name prometheus-operator --namespace monitoring stable/prometheus-operator

Deleting

helm del --purge prometheus-operator
kubectl delete ns monitoring
kubectl delete crd alertmanagers.monitoring.coreos.com podmonitors.monitoring.coreos.com prometheuses.monitoring.coreos.com prometheusrules.monitoring.coreos.com servicemonitors.monitoring.coreos.com
kubectl delete service -n kube-system prometheus-prometheus-oper-kubelet

values.yaml

https://github.com/helm/charts/blob/master/stable/prometheus-operator/values.yaml

OpenID для входа в grafana

https://steemit.com/grafana/@timoschuetz/setting-up-grafana-oauth2-in-kubernetes
Вот пример настроек grafana для авторизации пользователей из Active Directory, которые аутентифицируются на Keycloak. Тут важно обратить внимание на то, что роли пользователей задаются в соответствии с группами, в которые входит пользователь (параметр role_attribute_path), а имена групп должны быть со слешем в начале: /Grafana_Editor (это видно в логах).

  grafana.ini:
    paths:
      data: /var/lib/grafana/data
      logs: /var/log/grafana
      plugins: /var/lib/grafana/plugins
      provisioning: /etc/grafana/provisioning
    analytics:
      check_for_updates: true
    log:
      mode: console
      level: debug
    grafana_net:
      url: https://grafana.net
    server:
      root_url: "https://grafana.domain.local"
    auth.basic:
      enabled: false
      oauth_auto_login: true
      disable_login_form: true
    auth.generic_oauth:
      enabled: true
      tls_skip_verify_insecure: true
      name: keycloak
      allow_sign_up: true
      client_id: grafana
      client_secret: 12345678-123345678-12345678
      scopes: groups profile email
      #https://grafana.com/docs/grafana/latest/auth/generic-oauth/#jmespath-examples
      role_attribute_path: contains(groups[*], '/Grafana_Admin') && 'Admin' || contains(groups[*], '/Grafana_Editor') && 'Editor' || 'Viewer'
      auth_url: https://sso.domain.local/auth/realms/ad_realm/protocol/openid-connect/auth
      token_url: https://sso.domain.local/auth/realms/ad_realm/protocol/openid-connect/token
      api_url: https://sso.domain.local/auth/realms/ad_realm/protocol/openid-connect/userinfo
      signout_redirect_url: https://sso.domain.local/auth/realms/ad_realm/protocol/openid-connect/logout?redirect_uri=https://grafana.domain.local/login

deploy_rsyslog_on_kubernetes

anonymous@undisclosed.example.com (Anonymous) — Fri, 10 Jan 2020 10:30:52 +0000

https://github.com/rsyslog/rsyslog-docker/tree/master/appliance/alpine

kind: Namespace
apiVersion: v1
metadata:
  name: rsyslog
  labels:
    name: rsyslog
---
apiVersion: apps/v1
kind: Deployment
metadata:    
  name: rsyslog
  namespace: rsyslog
spec:
  replicas: 1
  selector:  
    matchLabels:
      app: rsyslog
  template:  
    metadata:
      labels:
        app: rsyslog
    spec:
      containers:    
        - name: rsyslog
          image: rsyslog/syslog_appliance_alpine:latest
          
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: rsyslog-config
  namespace: rsyslog
data:
  nginx.conf: |

---
apiVersion: v1
kind: Service
metadata:
  name: rsyslog-tcp
  namespace: rsyslog
spec:
  selector: 
    app: rsyslog
  type: ClusterIP
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80

dns_hints

anonymous@undisclosed.example.com (Anonymous) — Mon, 22 Aug 2022 09:57:43 +0000

DNS Lookup в чистом Debian

Мне нужно в чистом контейнере Haproxy на базе Debian Bullseye выполнить запрос к DNS и убедиться что имя резолвится. Оказалочь, что там есть perl и это можно сделать во такой строкой в shell:

perl -MSocket -le'my $ip = gethostbyname("ya.ru"); if(defined $ip){exit 0}else{exit 1}'

docker

anonymous@undisclosed.example.com (Anonymous) — Fri, 06 Dec 2019 20:27:43 +0000

Скачать(обновить) все docker images

docker images |grep -v REPOSITORY|awk '{print $1}'|xargs -L1 docker pull

Удалить ненужные docker images

В данном случае - удаляю amazon/opendistro-for-elasticsearch

docker images | grep 'amazon/opendistro-for-elasticsearch' | awk '{print $3}' | xargs -L1 docker rmi

docker_registry_auth_using_curl

anonymous@undisclosed.example.com (Anonymous) — Thu, 28 Apr 2022 06:08:01 +0000

DOCKER_KEY=$(cat ~/.docker/config.json | jq '.auths["https://index.docker.io/v1/"].auth')

TOKEN=$(curl -X GET https://auth.docker.io/token?service=registry.docker.io&scope=repository:${REPO}:pull -H "Authorization: Basic ${DOCKER_KEY}") | jq -r .token

curl -s -X GET https://registry.hub.docker.com/v2/repositories/${REPO}/tags/ -H "Authorization: Bearer ${TOKEN}"

для GCP:

#!/usr/bin/env bash

GCP_PROJECT_ID=...
MY_IMAGE=...

USERNAME=_json_key
PASSWORD=$(cat keyfile.json)

TOKEN=$(echo "$USERNAME:$PASSWORD" | base64)

RESPONSE=$(curl --header "Authorization: Basic $TOKEN" "https://gcr.io/v2/token?service=gcr.io&scope=registry:$GCP_PROJECT_ID/$MY_IMAGE:*")

REGISTRY_TOKEN=$(echo $RESPONSE | jq -r '.token')

echo "Registry token: $REGISTRY_TOKEN"
curl --header "Authorization: Bearer $REGISTRY_TOKEN" "https://gcr.io/v2/$GCP_PROJECT_ID/$MY_IMAGE/manifests/latest"
echo

Для Yandex Cloud:

fast_helm_carts

anonymous@undisclosed.example.com (Anonymous) — Wed, 07 Sep 2022 14:30:40 +0000

https://github.com/k8s-at-home/library-charts/

apiVersion: v2
description: Function library for k8s-at-home charts
home: https://github.com/k8s-at-home/library-charts/tree/main/stable/common

Собственно библиотека - https://github.com/bjw-s/helm-charts/tree/main/charts/library/common Пример чарта (фактически темплейт) - https://github.com/bjw-s/helm-charts/tree/main/charts/other/app-template

free_helm_chart_repository_with_github_pages

anonymous@undisclosed.example.com (Anonymous) — Thu, 02 Apr 2026 12:35:43 +0000

Публикуем helm chart на GitHub Pages с помощью GitHub Actions

Создаем в репе в ветке main директорию charts
Создаем в директории сharts собственно директорию helm-чарта Например с помощью
```
cd charts
helm create your-chart-name
```

Создаем директорию ./.github/workflows/ и в ней файлик publish-charts.yml с таким содержимым:

name: Release Charts
on:
  push:
    branches:
      - main
jobs:
  release:
    # depending on default permission settings for your org (contents being read-only or read-write for workloads), you will have to add permissions
    # see: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token
    permissions:
      contents: write
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Configure Git
        run: |
          git config user.name "$GITHUB_ACTOR"
          git config user.email "$GITHUB_ACTOR@users.noreply.github.com"
      - name: Run chart-releaser
        uses: helm/chart-releaser-action@v1.7.0
        env:
          CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}"

Коммитим в ветке main то что там теперь есть и пушим:
```
git add .
git commit -am 'helm chart'
git push
```

Теперь создаем пустую ветку gh-pages в которой собственно и будут публиковаться чарты:

git checkout --orphan gh-pages
git rm -rf .
rm '.gitignore'
echo "#Readme" > README.md
git add README.md
git commit -a -m "gh-pages"
git push -u origin gh-pages

В настройках репозитория на GitHub включаем публикацию GitHub Pages из ветки gh-pages: Settings → Pages (слева) → в Branch выбираем ветку gh-pages
Ну и все. После того как в Actions проудет публикация - можно ставить чарт:
```
helm repo add my-repo https://<owner>.github.io/<repoName>/
helm install my-chart my-repo/my-chart-name
```

git

anonymous@undisclosed.example.com (Anonymous) — Mon, 16 Mar 2026 10:20:51 +0000

много рецептов: https://webhamster.ru/mytetrashare/index/mtb0/

Ветвление и слияние веток

Клонируем репозиторий:

git clone https://....

Создаем ветку:

git branch new-branch

и переключаемся на нее:

git checkout new-branch

или обе команды в одной (создаем и сразу переключаемся на ветку):

git checkout -b new-branch

Увидеть какие ветки есть можно так:

git branch -a

Слияние веток

Например - есть две ветки master и new-branch.
Когда говорят, что нужно слить ветку new-branch с веткой master, то это значит, что нужно выполнить переключение на ветку master:

git checkout master

и выполнить слияние ветки new-branch:

git merge new-branch

Разрешение конфликтов при слиянии

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

Состояние первой ветки
Состояние второй ветки
Общее начальное состояние веток до изменений.

Включить отображение различий и общего начального стсоояния можно так:

git config merge.conflictstyle diff3

Допустим, была ветка master, от которой ответвились две ветки - develop и feature, в которых были произведены изменения в одном и том же файле.
При попытке слияния ветки feature с веткой develop:

git checkout develop
git merge feature

будет создан коммит, в котором зафиксирован конфликт двух веток:

Auto-merging main.go
CONFLICT (content): Merge conflict in main.go
Automatic merge failed; fix conflicts and then commit the result.

Увидеть суть конфликта можно в конце листинга указанного файла:

cat ./main.go
...
<<<<<<< HEAD
func sum (a, b int) int {
  return a + b
||||||| merged common ancestors
func sum (a, b int) int {
  t := a + b
  return t
=======
func sum(a, b int) int {
        t := a + b
        return t
>>>>>>> feature
}

Тут три фрагмента:

Первый принадлежит ветке develop:

func sum (a, b int) int {
  return a + b
}

Второй - принадлежит общему предку - коммиту в ветке master:

func sum (a, b int) int {
  t := b + a
  return t
}

Третий - ветке feature

func sum(a, b int) int {
        t := a + b
        return t
}

Теперь нужно как-то разрешить конфликт. Например, мы знаем, что нужно оставить самые последние версии (по времени внесения изменений).
Отлично написано тут: https://www.rosipov.com/blog/use-vimdiff-as-git-mergetool/
Для разрешения конфликта будем использовать дефолтную утилиту vimdiff.
Настраиваем git для использования vimdiff в качестве mergetool:

git config merge.tool vimdiff
git config mergetool.prompt false

Приступаем к разрешению конфликта:

git mergetool

Листаем вниз и видим конфликт:

  func sum (a, b int) int {               |  func sum (a, b int) int {               |  func sum(a, b int) int {                
    return a + b                          |    t := a + b                            |          t := a + b                      
  ----------------------------------------|    return t                              |          return t                        
  ----------------------------------------|  ----------------------------------------|  ----------------------------------------
  ----------------------------------------|  ----------------------------------------|  ----------------------------------------
  ----------------------------------------|  ----------------------------------------|  ----------------------------------------
  ----------------------------------------|  ----------------------------------------|  ----------------------------------------
  ----------------------------------------|  ----------------------------------------|  ----------------------------------------
  ----------------------------------------|  ----------------------------------------|  ----------------------------------------
  ----------------------------------------|  ----------------------------------------|  ----------------------------------------
./main_LOCAL_25754.go   44,2           97% ./main_BASE_25754.go    45,2           97% ./main_REMOTE_25754.go  45,2           97%
  <<<<<<< HEAD                                                                                                                  
  func sum (a, b int) int {                                                                                                     
    return a + b                                                                                                                
  ||||||| merged common ancestors                                                                                               
  func sum (a, b int) int {                                                                                                     
    t := a + b                                                                                                                  
    return t                                                                                                                    
  =======                                                                                                                       
  func sum(a, b int) int {                                                                                                      
          t := a + b                                                                                                            
          return t                                                                                                              
main.go                                                                                                       47,8           95%

Тут мы видим:

слева - состояние ветки в которую мерджим изменения (обозначены LOCAL)
в середине - общий предок (BASE)
справа - состояние ветки которую мы мерджим (REMOTE)
Внизу - конфликт

Нужно оставить изменения, которые содержатся в ветке REMOTE. Для этого переключаемся между окошками с помощью Ctrl + w,j на нижнее окошко, листам вниз до конфликта и жмем последовательно:

Esc
:diffg RE
:wqa

Эта последовательность команд переводит редактор в режим команд (кнопочка Esc), затем применяем изменения из ветки REMOTE, а затем сохраняем изменения.
Измнения из LOCAL или BASE применяются соответственно командами:

diffg BA

diffg LO

И наконец можно выполнить commit:

git commit -a -m "Branch 'feature' merged to 'develop'"

Разрешение всех конфликтов слияния в пользу текущего или входящего состояния

Если при merge возникли конфиликты, то можно одной командой разрешить все конфликты в ту или другую пользу.

Оставить все конфликтные участки в текущем состоянии:

git checkout --ours .

Применить во всех случаях конфликтов входящие изменения:

git checkout --theirs .

Переключиться на нужный коммит

Находим нужный коммит с помощью

git log

И переключаемся на него:

git checkout <commit_hash>

Тегирование коммитов

Тегируем текущий коммит и пушим тег:

git tag <tag_name>
git push <remote_name> <branch_name> <tag_name>

Например:

git tag ops.07
git push origin master ops.07

Откат изменений

git reset --hard

Откат определенных коммитов (rebase & cherry-pick vs. revert): https://www.pixelstech.net/article/1549115148-git-reset-vs-git-revert

git revert ...

Объединение коммитов

https://git-scm.com/book/ru/v1/%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B-Git-%D0%9F%D0%B5%D1%80%D0%B5%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C-%D0%B8%D1%81%D1%82%D0%BE%D1%80%D0%B8%D0%B8
Объединить коммиты можно с помощью interactive rebase:

git rebase -i HEAD~3

Откроется тектовый редактор, в котором в начале будут перечислены коммиты (в данном случае - 3 штуки, начиная с самого старого) и применяемые к ним действия (по умолчанию - pick). Для того, чтобы объединить коммиты нужно для самого первого (старого) оставить pick, а для остальных прописать squash (или сокращенно s). В результате, изменения в коммитах объединятся в один (самый старый).

Объединение всех коммитов ветки

git reset `echo "Total Squash Commit" | git commit-tree HEAD^{tree}`

Разбиение коммитов и распределение их по веткам

Предствьте себе, что случилась неприятность - вы недумая коммитили в master, в одном коммите могли оказаться изменения, касающиеся разных фич. И всё было хорошо, пока кто-то не захотел сделать ревью и увидел ХАОС. Что нужно - нужно разбить сделанные коммиты по веткам фич. Для этого - нужно разбить все старые коммиты и потом применить их к нужным веткам. Как разбить коммит, который зарыт глубоко в истории?? Поможет rebase! Что он делает - применяет коммиты последовательно к тому, на котором мы делаем rebase. Как вмешаться в этот процесс - запустить его в интерактивном режиме, когда мы можем указать что делать с каждым коммитом.
Допустим - у нас поверх последнего хорошего коммита выполнено уже 4 нехороших хаотичных. Первое - выполняем интерактивный ребейс:

git rebase -i HEAD~4

Либо прямо делаем rebase, указав хеш коммита:

git rebase -i <LAST_GOOD_COMMIT>

Откроется окно редактора, в котором будет список коммитов, начиная с самого старого. На против каждого будет стоять pick. Если сейчас ничего не менять - то ничего и не произойдет. Все коммиты применятся и мы откажемся на последнем. Но! Если для первого поставить вместо pick - edit, сохраним файлик и выйдем, то мы окажемся на этом коммите. А дальше - магия git. \ Отменяем коммит, на котором мы находимся в данный момент (который был закоммичен последним с нашей точки зрения - а это тот, для которого мы указали edit):

git reset HEAD~

Проверим, что изменения откатились и увидим список измененных в этом коммите файлов:

git status

Например, файлы разбиты по каталогам feature1 и feature2 (будем считать так для простоты). Нам надо разбить изменения в этих каталогах на два коммита. Последовательно добавляем в stage каталоги (или файлы) и коммитим:

git add ./feature1/*
git commit -m 'feature1 commit'
git add ./feature2/*
git commit -m 'feature2 commit'

В итоге наш крупный коммит был разбит на два. А теперь - продолжим rebase:

git rebase --continue

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

git checkout <LAST_GOOD_COMMIT>
git checkout -b feature1
git cherry-pick <FEATURE1_SHA1>

и для второй фичи:

git checkout <LAST_GOOD_COMMIT>
git checkout -b feature2
git cherry-pick <FEATURE2_COMMIT_SHA1>

Скачать из репозитория git одну единственную папку

mkdir charts
cd charts
git init
git remote add origin https://github.com/helm/charts.git
git config core.sparseCheckout true
echo "stable/jenkins" > .git/info/sparse-checkout
git pull origin master

или

git archive --format tar --remote ssh://server.org/path/to/git HEAD docs/usage > /tmp/usage_docs.tar

Почистить репозиторий git

Допустим, у нас не было файлика .gitignore и в репозиторий попало много ненужного.
Теперь я хочу избавиться от ненужных файлов в репозитории.
Для этого:

делаем коммит текущего состояния, вместе с файликом .gitignore
удаляем все ненужные файлики из репы
удаляем все файлики из индекса репозитория ( отдельный файлик можно удалить так: git rm –cached foo.txt )

git rm -r --cached .

и добавляем все файлики обратно в индекс:

git add .

Коммитим состояние

git commit -m ".gitignore fix"

No url found for submodule path

Иногда в проект попадают подпроекты, которые сами по себе являются репозиториями git. В этому случае они становятся submodules и git работает с ними как со ссылками на внешние репы. То есть он не сохраняет в репозитории файлы этих проектов, а скачивает их по требованию.
Однако, может так статься, что файлы подпроекта становятся частью проекта, а ссылки на внешние репозитории изменяются или перестают работать.
Если ссылка на внешний репозитрий изменилать, то следует поправить ее в файле .gitmodules в корне проекта:

[submodule "path_to_submodule"] 
  path = path_to_submodule 
  url = git://url-of-source/

А если подпроект нужно просто сделать частью проекта, то удаляем его так:

git rm --cached path_to_submodule

fatal: refusing to merge unrelated histories

Иногда, после манипуляций с историей коммитов нарушается связность историй веток и при попытке выполнения

git merge BRANCHNAME

Появляется сообщение вида:

fatal: refusing to merge unrelated histories

В этом случае - если нам нужно заменить содержимое одной ветки, содержимым другой, то в ветке куда делаем merge выполняем:

git pull origin BRANCHNAME -X theirs --allow-unrelated-histories

То есть - подтягиваем в текущую ветку все изменения из ветки репозитория BRANCHNAME, разрешаем нарушение истории коммитов (–allow-unrelated-histories) и автоматически разрешаем все конфликты в пользу применения входящих изменений (-X theirs)

Создать пустой коммит перед корневым

https://qastack.ru/programming/645450/insert-a-commit-before-the-root-commit-in-git

Удалить большие файлы из репозитория git

Найти большие файлы в текущей репе git:

git rev-list --objects --all | grep -f <(git verify-pack -v  .git/objects/pack/*.idx| sort -k 3 -n | cut -f 1 -d " " | tail -10)

или так:

git rev-list --objects --all | while read sha1 fname; do   echo -e "$(git cat-file -s $sha1)\t$fname"; done | sort -n -r | head -n 20

Удаляем те файлики, которые не нужны, используя пути к ним:

git filter-repo --path-glob '~~~FILE_PATH~~~' --invert-paths --force

Либо - можно удалять по расширению:

git filter-repo --path-glob '*.zip' --invert-paths --force

Теперь надо снова прописать remote

git remote add origin git@github.com:.........

И запушить всё:

git push --all --force
git push --tags --force

github_git_clone_decryption_has_failed

anonymous@undisclosed.example.com (Anonymous) — Thu, 12 Jan 2023 07:07:33 +0000

GitHub - git clone - Decryption has failed

OS - 22.04.1 LTS (Jammy Jellyfish). git - установлен из репозития
При попытке склонировать репозиторий с GitHub операция завершается с ошибкой:

remote: Enumerating objects: 3094, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
error: RPC failed; curl 56 GnuTLS recv error (-24): Decryption has failed.
error: 5651 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

Что НЕ помогло

apt install gnutls-bin

git config --global http.postBuffer 1048576000
git config --global https.postBuffer 1048576000
git config --global http.sslVerify false
git config --system core.longpaths true
git config --global core.compression -1
unset all_proxy && unset ALL_PROXY
git config --global http.proxy ""

Что помогло

Причиной оказались настройки точки доступа Wi-Fi. Скорее всего - MTU.
Проблема решилась после переключения на другую точку доступа.

gitlab

anonymous@undisclosed.example.com (Anonymous) — Sun, 09 Jan 2022 20:55:50 +0000

Терминология Gitlab

В Gitlab многие сущности именуются несколько иначе, чем в других системах:

Название в GitLab	Что это	Названия в других CMS
Проект (Project)	Базовый элемент рабочего процесса, включающий в себя код приложения и связанные с ним сущности (задачи, документацию, пайплайн CI/CD и другое)	Репозиторий (Repository)
Группа (Group)	Именованный набор проектов и/или групп (напоминает директории). Группы могут быть вложенными и могут включать в себя не только проекты, но и учетные записи разработчиков для раздачи прав. Gitlab поддерживает до 20 уровней вложенных групп.	Проект (Project)
Задача (Issue)	Задачи - это базовые элементы планирования, связанные с проектами. Используются для планирования, контроля выполнения и документирования работ	Story, Narrative, Ticket
Эпик (Epic)	Эпик - это набор связанных по смыслу задач, в разных проектах и их группах. Для Эпиков поддерживается иерархия - дочерние эпики. Поддерживаются в редакциях Premium и Ultimate	Initiatives, Themes
Merge Request	MR позволяет связать задачу (issue) и коммиты кода, реализующие эту задачу, а также все сопутствующие детали (обсуждения, результаты review и прочее)	Pull Request
Метка (Label)	Метки относятся к задачам и позволяют обозначать различные состояния работы над ними. Это не теги коммитов git. Это именно метки для задач (Issues)	Tag
Доска (Board)	Доска позволяет визуализировать текущее состояние проектов и задач для удобного планирования работы	-
Майлстоун (Milestone)	Группа выполненных (готовых к доставке) задач и связанных с ними изменений кода	Релиз (Release)
Дорожная карта (Roadmap)	Визуализация эпиков для группы проектов. Необходима редакция Ultimate	-

Примеры CI/CD

gitlab_ci_gke

anonymous@undisclosed.example.com (Anonymous) — Wed, 09 Sep 2020 15:00:57 +0000

Практикуюсь в построении CI на базе GitLab и GKE

Итак. У меня есть стандартное тестовое приложение https://github.com/GoogleCloudPlatform/microservices-demo
Я залил этот репозиторий на https://gitlab.com/dashboard/projects

Предполагаю, что на машинке установлен и инициализирован gcloud и terraform.

Разворачиваем кластер Kubernetes на GKE

git clone https://gitlab.com/mike.obninsk/gke_cluster.git
cd gke_cluster
terrafrom init
terraform plan
terraform apply

Получаем учетные данные для кластера :

KUBECONFIG=./kubeconfig gcloud container clusters get-credentials otus-project-cluster --zone us-east1-b --project otus-kuber-course

В результате в текущей директории в файлике kubeconfig будет содержаться конфиг для доступа к кластеру.

gitlab_ci_semver

anonymous@undisclosed.example.com (Anonymous) — Wed, 27 Apr 2022 08:03:44 +0000

Какие вараинты я расмотрел

https://github.com/mrooding/gitlab-semantic-versioning - относительно простой скрипт на питоне. Преимущества - может просто работать на ранненере, при наличии питона, либо - в Docker'е
https://semantic-release.gitbook.io/semantic-release/
https://threedots.tech/post/automatic-semantic-versioning-in-gitlab-ci/ - вот какое-то тоже решение на питончике

gslb

anonymous@undisclosed.example.com (Anonymous) — Wed, 02 Nov 2022 10:59:24 +0000

Polaris

https://github.com/polaris-gslb/polaris-gslb

An extendable high availability solution for the data center and beyond, Global Server Load Balancing(GSLB), DNS-based traffic manager.

haproxy_hints

anonymous@undisclosed.example.com (Anonymous) — Tue, 16 Aug 2022 15:20:32 +0000

Доступные Samples - свойства для stick on

https://cbonte.github.io/haproxy-dconv/2.5/configuration.html#7.3.6

Посмотреть содержимое sticky tables

https://stackoverflow.com/a/51065175

stats socket /var/lib/haproxy/stats


bash#> echo "show table" | socat unix-connect:/var/lib/haproxy/stats stdio
# table: BACKEND_NAME, type: binary, size:20971520, used:2

bash#>echo "show table BACKEND_NAME" | socat unix-connect:/var/lib/haproxy/stats stdio
# table: BACKEND_NAME, type: binary, size:20971520, used:2
0x7f9ca0f24314:
key=8A3DF855010388A4DD94F71E0FEAF7A54A7032EA56D477D20F59B4F28CEF183B use=0
exp=1264499 server_id=1
0x7f9ca0f245c4:
key=C7EA05BA85730EAF725035EFB3C4F7537FCCCFD0469FB45A4A2DE85308ECF1C7 use=0
exp=1696667 server_id=2

hashicorp_vault_workflow

anonymous@undisclosed.example.com (Anonymous) — Thu, 13 Aug 2020 19:48:12 +0000

О чем это

Тут некоторе заметки по поводу использования HashiCorp Vault.
HashiCorp Vault реализует API для безопасного доступа к сенситивным данным. Он шифрует/дешифрует их и передает/извлекает в/из хранилища, в качестве которого могут выступать как обычные файлы, так и базы данных (mysql), key-value хранилища (etcd), но рекомендуемым является Hashicorp Consul.

Все эксперименты провожу в отдельном неймспйсе:

kubectl create ns vault

Установка Hashicorp Vault

Установим Consul

helm upgrade --install consul -n vault ./consul-helm/ --set server.replicas=1   --set server.bootstrapExpect=1

Установим Vault:

helm upgrade --install vault -n vault ./vault-helm/ --set server.standalone.enabled=false --set server.ha.enabled=true --set server.ha.replicas=1 --set ui.enabled=true --set ui.serviceType: "ClusterIP"

Убедимся, что всё запустилось:

kubectl get po -n vault

Инициализация Vault

kubectl exec -it -n vault vault-0 -- vault operator init --key-shares=1  --key-threshold=1

В ответ получим что-то такое:

Unseal Key 1: EEvC8nTJ7gw1SQtMJIly6JKtk6SWm+DyJWGycq/ECq4=

Initial Root Token: s.Ta90nQ3ynlOEqkWm4g0WiJRJ

Vault initialized with 1 key shares and a key threshold of 1. Please securely
distribute the key shares printed above. When the Vault is re-sealed,
restarted, or stopped, you must supply at least 1 of these keys to unseal it
before it can start servicing requests.

Vault does not store the generated master key. Without at least 1 key to
reconstruct the master key, Vault will remain permanently sealed!

It is possible to generate new unseal keys, provided you have a quorum of
existing unseal keys shares. See "vault operator rekey" for more information.

Теперь поглядим статус Vault:

kubectl exec -it -n vault vault-0 -- vault status -tls-skip-verify

И получим такое:

Key                Value
---                -----
Seal Type          shamir
Initialized        true
Sealed             true
Total Shares       1
Threshold          1
Unseal Progress    0/1
Unseal Nonce       n/a
Version            1.4.2
HA Enabled         true
command terminated with exit code 2

Тут видно, что Vault запечатан (Sealed true). Распечатаем его:

kubectl exec -it vault-0 -n vault -- vault operator unseal

Если Vault развернут в HA-конфигурации, то распечатать нужно каждую реплику.

kubectl exec -it vault-0 -- vault operator unseal

Работа с данными в Vault

Для начала нужно залогиниться в Vault (получить токен для доступа к API):

kubectl exec -it vault-0 -n vault -- vault login

Тут нужно ввести root token, полученный при инициализации Vault.
Теперь запросим список хрянящихся в Vault авторизаций:

kubectl exec -it -n vault vault-0 -- vault auth list

Создадим путь (директорию) для хранения секретов:

kubectl exec -it -n vault vault-0 -- vault secrets enable --path=otus kv

Посмотрим список существующих секретов:

kubectl exec -it -n vault vault-0 -- vault secrets list --detailed

Создадим пару секретов в нашей “директории”

kubectl exec -it -n vault vault-0 -- vault kv put otus/otus-ro/config username='otus' password='asajkjkahs'
kubectl exec -it -n vault vault-0 -- vault kv put otus/otus-rw/config username='otus' password='asajkjkahs'

И теперь прочитаем их:

kubectl exec -it -n vault vault-0 -- vault read otus/otus-ro/config
kubectl exec -it -n vault vault-0 -- vault kv get otus/otus-rw/config

Интеграция с Kubernetes

Базовый вариант использования Vault с Kubernetes подразумевает чтение секретов из Vault. Для этого используются init-контейнер vault-agent, который читает из Vault секрет и помещает его в файл-шаблон.
Включим авторизацию через Kubernetes:

kubectl exec -it -n vault vault-0 -- vault auth enable kubernetes

И убедимся, что она включилась:

kubectl exec -it -n vault vault-0 -- vault auth list

Создадим ServiceAcccount

kubectl create serviceaccount -n vault vault-auth

И дадим ей права с помощью CLusterRoleBinding:

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: role-tokenreview-binding
  namespace: vault
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: vault-auth
  namespace: vault
EOF

Теперь мы сконфигурируем в Vault параметры аутентификации для доступа к Kubernetes:

export VAULT_SA_NAME=$(kubectl get sa vault-auth -n vault -o jsonpath="{.secrets[*]['name']}")
export SA_JWT_TOKEN=$(kubectl get secret $VAULT_SA_NAME -n vault -o jsonpath="{.data.token}" | base64 --decode; echo)
export SA_CA_CRT=$(kubectl get secret $VAULT_SA_NAME -n vault -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echo)
#export K8S_HOST=$(more ~/.kube/config | grep server |awk '/http/ {print $NF}')
export K8S_HOST="https://kub:6443"

И сконфигурируем аутентификацию (вернее поместим полученные значения в Vault):

kubectl exec -it -n vault vault-0 -- vault write auth/kubernetes/config token_reviewer_jwt="$SA_JWT_TOKEN" kubernetes_host="$K8S_HOST" kubernetes_ca_cert="$SA_CA_CRT"

Дальше нужно дать права на доступ к секретам (вернее к “директориям”) в Vault. Для этого - создади файлик политики:

tee otus-policy.hcl <<EOF
path "otus/otus-ro/*" {
capabilities = ["read", "list"]
}
path "otus/otus-rw/*" {
capabilities = ["read", "create", "list", "update"]
}
EOF

скопируем его в pod vault'а:

kubectl -n vault cp otus-policy.hcl vault-0:/tmp/

и создадим с его помощью политику:

kubectl -n vault exec -it vault-0 -- vault policy write otus-policy /tmp/otus-policy.hcl

а также - создаим роль в vault:

kubectl -n vault exec -it vault-0 -- vault write auth/kubernetes/role/otus bound_service_account_names=vault-auth bound_service_account_namespaces=default policies=otus-policy ttl=24h

Проверка аутентификации и авторизации pod'а в Vault

Сейчас нужно запустить pod с ServiceAccount, которая была создана ранее и попытаться залогиниться в Vault с помощью токена этой ServiceAccount:

kubectl run -n vault --generator=run-pod/v1 tmp --rm -i --tty --serviceaccount=vault-auth --image alpine:3.7

В результате выполнения этой команды моявится приглашение командной строки внутри запущенного контейнера. Установим в контейнере curl и jq

apk add curl jq

И попытаемся залогиниться в Vault (также внутри тестового контейнера):

VAULT_ADDR=http://vault:8200
KUBE_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
curl --request POST --data '{"jwt": "'$KUBE_TOKEN'", "role": "otus"}' $VAULT_ADDR/v1/auth/kubernetes/login | jq
TOKEN=$(curl -k -s --request POST --data '{"jwt": "'$KUBE_TOKEN'", "role": "otus"}' $VAULT_ADDR/v1/auth/kubernetes/login | jq '.auth.client_token' | awk -F\" '{print $2}')

В итоге у нас должно получиться значение токена:

echo $TOKEN
s.ZmPegZEMIbB3pzBavjSWDLab

И теперь с помощью этого токена можно почитать секреты:

curl --header "X-Vault-Token:s.pPjvLHcbKsNoWo7zAAuhMoVK" $VAULT_ADDR/v1/otus/otus-ro/config
curl --header "X-Vault-Token:s.pPjvLHcbKsNoWo7zAAuhMoVK" $VAULT_ADDR/v1/otus/otus-rw/config

или записать секреты:

curl --request POST --data '{"bar": "baz"}' --header "X-Vault-Token:s.pPjvLHcbKsNoWo7zAAuhMoVK" $VAULT_ADDR/v1/otus/otus-rw/config

Теперь можно сконфигурировать тестовый под, который сможет забрать секреты из Vault. Объекты создадим на базе примеров: https://github.com/hashicorp/vault-guides/tree/master/identity/vault-agent-k8s-demo

Configmap

kubectl apply -f - <<EOF
apiVersion: v1
data:
  vault-agent-config.hcl: |
    # Comment this out if running as sidecar instead of initContainer
    exit_after_auth = true

    pid_file = "/home/vault/pidfile"

    auto_auth {
        method "kubernetes" {
            mount_path = "auth/kubernetes"
            config = {
                role = "otus"
            }
        }

        sink "file" {
            config = {
                path = "/home/vault/.vault-token"
            }
        }
    }

  consul-template-config.hcl: |
    vault {
      renew_token = false
      vault_agent_token_file = "/home/vault/.vault-token"
      retry {
        backoff = "1s"
      }
    }
    template {
    destination = "/etc/secrets/index.html"
    contents = <<EOT
    <html>
    <body>
    <p>Some secrets:</p>
    {{- with secret "otus/otus-ro/config" }}
    <ul>
    <li><pre>username: {{ .Data.username }}</pre></li>
    <li><pre>password: {{ .Data.password }}</pre></li>
    </ul>
    {{ end }}
    </body>
    </html>
    EOT
    }
kind: ConfigMap
metadata:
  name: example-vault-agent-config
  namespace: vault
EOF

pod

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: vault-agent-example
  namespace: vault
spec:
  serviceAccountName: vault-auth

  volumes:
  - configMap:
      items:
      - key: vault-agent-config.hcl
        path: vault-agent-config.hcl
      - key: consul-template-config.hcl
        path: consul-template-config.hcl
      name: example-vault-agent-config
    name: config
  - emptyDir: {}
    name: shared-data
  - emptyDir: {}
    name: vault-token    

  initContainers:
  - args:
    - agent
    - -config=/etc/vault/vault-agent-config.hcl
    - -log-level=debug
    env:
    - name: VAULT_ADDR
      value: http://vault:8200
    image: vault
    name: vault-agent
    volumeMounts:
    - mountPath: /etc/vault
      name: config
    - name: vault-token
      mountPath: /home/vault

  containers:
  - image: nginx
    name: nginx-container
    ports:
    - containerPort: 80
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: shared-data

  - name: consul-template
    image: hashicorp/consul-template:alpine
    imagePullPolicy: Always
    volumeMounts:
      - name: vault-token
        mountPath: /home/vault
      - name: config
        mountPath: /etc/consul-template
      - name: shared-data
        mountPath: /etc/secrets
    env:
      - name: HOME
        value: /home/vault
      - name: VAULT_ADDR
        value: http://vault:8200
    args: ["-config=/etc/consul-template/consul-template-config.hcl"]
EOF

Запуск Certification Authority на базе Vault

https://www.vaultproject.io/docs/secrets/pki

создадим CA на базе vault

Включим секреты pki и сконфигурирум некоторые параметры:

kubectl exec -it -n vault vault-0 -- vault secrets enable pki
kubectl exec -it -n vault vault-0 -- vault secrets tune -max-lease-ttl=87600h pki

Сгенерируем сертификат CA:

kubectl exec -it -n vault vault-0 -- vault write -field=certificate pki/root/generate/internal common_name="example.ru" ttl=87600h > CA_cert.crt

Пропишем ссылки для CA и проверки отозванных сертификатов

kubectl exec -it -n vault vault-0 -- vault write pki/config/urls issuing_certificates="http://vault:8200/v1/pki/ca" сrl_distribution_points="http://vault:8200/v1/pki/crl"

Создадим промежуточный сертификат

kubectl exec -it -n vault vault-0 -- vault secrets enable --path=pki_int pki
kubectl exec -it -n vault vault-0 -- vault secrets tune -max-lease-ttl=87600h pki_int
kubectl exec -it -n vault vault-0 -- vault write -format=json pki_int/intermediate/generate/internal common_name="example.ru Intermediate Authority" | jq -r '.data.csr' > pki_intermediate.csr

пропишем промежуточный сертификат в vault:

kubectl cp pki_intermediate.csr -n vault vault-0:/tmp/
kubectl exec -it -n vault vault-0 -- vault write -format=json pki/root/sign-intermediate csr=@/tmp/pki_intermediate.csr format=pem_bundle ttl="43800h" | jq -r '.data.certificate' > intermediate.cert.pem
kubectl cp intermediate.cert.pem -n vault vault-0:/tmp/
kubectl exec -it -n vault vault-0 -- vault write pki_int/intermediate/set-signed certificate=@/tmp/intermediate.cert.pem

Создадим и отзовем новые сертификаты

Создадим роль для выдачи сертификатов

kubectl exec -it -n vault vault-0 -- vault write pki_int/roles/example-dot-ru allowed_domains="example.ru" allow_subdomains=true max_ttl="720h"

Создадим и отзовем сертификат

kubectl exec -it -n vault vault-0 -- vault write pki_int/issue/example-dot-ru common_name="test.example.ru" ttl="24h"
kubectl exec -it -n vault vault-0 -- vault write pki_int/revoke serial_number="71:a8:4f:4c:bd:74:c6:d8:ea:27:64:cb:53:ef:80:1a:6b:c8:be:e3"

Автоматическое обновление сертификатов с помощью consul-template

https://medium.com/hashicorp-engineering/certificates-issuing-and-renewal-with-vault-and-consul-template-18e766228dac
https://learn.hashicorp.com/tutorials/nomad/vault-pki-nomad
Как все работает.

в деплойменте пода помимио прикладного контейнера (nginx) прописываются два дополнительных контейнера. Первый - init-контейнер vault-agent, который берет конфигурацию из конфигмапа и получает токен. Этот токен в дальнейшем использует второй контейнер - consul-template, который занимается тем, что обновляет данные в соответствии с темплейтом записаным в конфигмап. Обновленные данные он кладет в папку, которая смонтирована в него и в прикладной под с nginx.
Для того, чтобы все работало в Vault должна быть заведена политика, которая бы разрешала доступ для заданной роли в путь, где выпускаются сертификаты.

Создадим файл политики, которая разрешить выпуск сертификатов с помощью промежуточного CA:

tee cert_issue_policy.hcl <<EOF
path "pki_int/issue/*" {
    capabilities = ["create", "read", "update", "list"]
}
EOF

скопируем файл политики в vault:

kubectl -n vault cp cert_issue_policy.hcl vault-0:/tmp/

и создадим с него помощью политику:

kubectl -n vault exec -it vault-0 -- vault policy write cert-issue-policy /tmp/cert_issue_policy.hcl

а также - создадим роль в vault, которую привяжем к ServiceAccount (с правами которого будет работать pod) и назначим этой роли созданную ранее политику, разрешающую выпуск сертов:

kubectl -n vault exec -it vault-0 -- vault write auth/kubernetes/role/cert-issue-role bound_service_account_names=vault-auth bound_service_account_namespaces=vault policies=cert-issue-policy ttl=24h

А теперь создадим объекты в K8S.

configmap

Конфигмап содержит три конфига:

для init-контейнера vault-agent, который аутентифицируется с помощью ServiceAccount и получит токен для контейнера consul-template
для consul-templateв котором описано где взять токен, поученный vault-agent, что именно забрать из vault (сертификат и ключ), куда это потом положить (в файлы) и что сделать после этого (послать сигнал nginx для обновления конфига).
конфиг nginx, в котором настроен HTTPS-сервер, использующий файлы сертификата и ключа, полученные из Vault.

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-cert-renew-config
  namespace: vault
data:
  vault-agent-config.hcl: |
    # Comment this out if running as sidecar instead of initContainer
    exit_after_auth = true

    pid_file = "/home/vault/pidfile"

    auto_auth {
        method "kubernetes" {
            mount_path = "auth/kubernetes"
            config = {
                role = "cert-issue-role"
            }
        }

        sink "file" {
            config = {
                path = "/home/vault/.vault-token"
            }
        }
    }

  consul-template-config.hcl: |
    vault {
      renew_token = false
      vault_agent_token_file = "/home/vault/.vault-token"
      retry {
        backoff = "1s"
      }
    }

    template {
        contents = "{{ with secret \"pki_int/issue/example-dot-ru\" \"common_name=test.example.ru\" \"ttl=2m\"}}{{ .Data.certificate }}{{ end }}"
        destination="/etc/secrets/tls.crt"
        command="sh -c 'killall -s HUP nginx || true'"
    }
    template {
        contents = "{{ with secret \"pki_int/issue/example-dot-ru\" \"common_name=test.example.ru\" \"ttl=2m\"}}{{ .Data.private_key }}{{ end }}"
        destination="/etc/secrets/tls.key"
    }
    template {
        contents = "{{ with secret \"pki_int/issue/example-dot-ru\" \"common_name=test.example.ru\" \"ttl=2m\"}}{{ .Data.issuing_ca }}{{ end }}"
        destination="/etc/secrets/int_ca.crt"
    }

  nginx_ssl.conf: |
    server {
      listen              443 ssl;
      server_name         test.example.ru;
      ssl_certificate     /etc/nginx/ssl/tls.crt;
      ssl_certificate_key /etc/nginx/ssl/tls.key;
      ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
      ssl_ciphers         HIGH:!aNULL:!MD5;

      location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
      }
    }

Pod

Манифест Pod'а с тремя контейнерами:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-cert-renew-example
  namespace: vault
  labels:
    app: nginx
spec:
  shareProcessNamespace: true
  serviceAccountName: vault-auth
  volumes:
  - configMap:
      items:
      - key: vault-agent-config.hcl
        path: vault-agent-config.hcl
      - key: consul-template-config.hcl
        path: consul-template-config.hcl
      name: nginx-cert-renew-config
    name: config
  - configMap:
      items:
      - key: nginx_ssl.conf
        path: nginx_ssl.conf
      name: nginx-cert-renew-config
    name: nginx-config
  - emptyDir: {}
    name: shared-data
  - emptyDir: {}
    name: vault-token    

  initContainers:
  - args:
    - agent
    - -config=/etc/vault/vault-agent-config.hcl
    - -log-level=debug
    env:
    - name: VAULT_ADDR
      value: http://vault:8200
    image: vault
    imagePullPolicy: IfNotPresent
    name: vault-agent
    volumeMounts:
    - mountPath: /etc/vault
      name: config
    - name: vault-token
      mountPath: /home/vault

  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: nginx-container
    ports:
    - containerPort: 80
    volumeMounts:
    - mountPath: /etc/nginx/ssl/
      name: shared-data
    - mountPath: /etc/nginx/conf.d/
      name: nginx-config
  - name: consul-template
    image: hashicorp/consul-template:alpine
    imagePullPolicy: IfNotPresent
    securityContext:
      runAsUser: 0
      capabilities:
        add:
        - SYS_PTRACE
    volumeMounts:
      - name: vault-token
        mountPath: /home/vault
      - name: config
        mountPath: /etc/consul-template
      - name: shared-data
        mountPath: /etc/secrets
    env:
      - name: HOME
        value: /home/vault
      - name: VAULT_ADDR
        value: http://vault:8200
    args: ["-config=/etc/consul-template/consul-template-config.hcl"]

Тут стоит обратить внимание на:

shareProcessNamespace: true

Эта конструкция позволяет иметь процессам всех контейнеров общий namespace, чтобы можно было управлять процессом nginx из контейнера consul-template.
Также важно, чтобы у контейнера consul-template был такой securityContext:

  securityContext:
    runAsUser: 0
    capabilities:
      add:
      - SYS_PTRACE

Это значит, что процессы этого контейнера будут исполняться с id=0 (то есть иметь права root с точки зрения всех процессов pod'а) и у процессов этого контейнера будут права посылать сигналы в другеи контейнеры (SYS_PTRACE). Подробнее тут - https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/

helm

anonymous@undisclosed.example.com (Anonymous) — Tue, 23 Mar 2021 11:32:14 +0000

Создание чартов helm

https://helm.sh/docs/topics/charts/
https://helm.sh/docs/chart_template_guide/getting_started/

Ошибка parse error at ...: bad character U+002D '-'

Такое происходит, если в имени параметра в values.yaml есть символ “-”.
Если переименовать параметр невозможно, то подставлять его следует с помощью конструкции index:

{{ index .Values "mysub-chart" "servicename" }}

Определение значений values.yaml через уже известные значения

https://github.com/helm/helm/issues/2492
https://github.com/helm/helm/issues/2492#issuecomment-589699208
Например, у меня есть чарт, который разворачивает кластер Elasticsearch с помощью Elasticsearch Operator. В составе этого чарта есть subchart, который разворачивает logstash.
В конфигурацию logstash должны попасть путь к elasticsearch и пароль для basic-аутентификации. FQDN-имя, по которому будет доступен Elastic формируется при разворачивании кластера и включает в себя имя релиза ( .Release.Name ), а пароль хотелось бы задать один раз, в одном месте в едином файле values.yaml!
Задача - сделать так, чтобы значения, определенные для кластера elasticsaerch стали доступны для logstash с минимальными изменениями в коде чарта logstash, а лучше даже и без них!

values.yaml

global:
  internalElasticUserPassword: AG7dGmsZp2NDpRED
  # пароль, который будет установлен для встроенного пользователя elastic.
  # Он будет использован как минимум дважды. Первый раз - при создании секрета с паролем пользователя в основном чарте кластера elasticsearch.
  # И второй раз - для создания переменной окружения logstash, которая будет использована в конфигурации output.
#.....
logstash:
  image:
    tag: |-
      {{ .Chart.AppVersion }}
      
  config:
    ELASTIC_PASSWORD: |-
      {{ tpl (printf "%s" .Values.global.internalElasticUserPassword) $ }}
    queue.max_bytes: 1gb
    queue.type: memory
    
  elasticsearch:
    host: |-
      {{ tpl (printf "%s%s%s%s" .Release.Name "-es-http." .Release.Namespace ".svc.cluster.local" ) $  }}
    port: 9200

  outputs:
    main: |-
      output {
              elasticsearch {
                  hosts => ["${ELASTICSEARCH_HOST}:${ELASTICSEARCH_PORT}"]
                  index => "etl-%{+YYYY.MM.dd}"
                  user => "elastic"
                  password => "${ELASTIC_PASSWORD}"
                  ssl => true
                  ssl_certificate_verification => false
              }
      }

а в statefullset.yaml субчарта logstash приводим соответствующие строки к такому виду:

        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ tpl .Values.image.tag . }}"
          
            ## Elasticsearch output
            - name: ELASTICSEARCH_HOST
              value: {{ tpl (.Values.elasticsearch.host | toString) . | quote }}
            
            ####
            
          {{- range $key, $value := .Values.config }}
            - name: {{ $key | upper | replace "." "_" }}
              value: {{ tpl ($value | toString ) $ | quote }}
          {{- end }}

То есть строки, указанные в values интерпретируются с помощью функции tpl.

templating in values hack

Например, у меня есть набор volumes, которые я хотел бы добавить к deployment, в именах которых присутствует название релиза - release.name. Стандартными средствами helm не позволяет темплейтинг в values.yaml, поэтому можно применить такой хак:
В темплейте deployment'а пишем такое:

{{- if .Values.volumes }}
{{- with .Values.volumes }}
{{/*      volumes: {{ toYaml .Values.volumes | nindent 8 }}*/}}
      volumes:
      {{- tpl . $ | nindent 8 }}
{{- end }}
{{- end }}

а в values пишем такое:

  volumes: |
    - name: volume1
      configMap:
        name: {{ .Release.Name }}-config1
    - name: volume2
      configMap:
        name: {{ .Release.Name }}-config2
    - name: volume3
      configMap:
        name: {{ .Release.Name }}-config3

В итоге - в deployment попадут

ingress_413_request_entity_too_large

anonymous@undisclosed.example.com (Anonymous) — Thu, 14 Nov 2019 12:02:07 +0000

Проблема

При upload'е через Ingress наблюдаю ошибку:

413 Request Entity Too Large

Решение

В раздел annotations декларации ingress'а нужно добавить:

  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"

java_app_cd_pipeline_with_jenkins

anonymous@undisclosed.example.com (Anonymous) — Mon, 18 Nov 2019 14:53:43 +0000

О чем это

Автоматизация сборки Java-приложения с помощью Jenkins в кластере Kubernetes
Вариация на тему туториалов:

Установка Jenkins в кластер Kubernetes

Установка Jenkins в кластер Kubernetes с помощью helm

Настройка jenkins для работы в кластере kubernetes

https://www.oracle.com/webfolder/technetwork/tutorials/obe/oci/configure_jenkins_kubernetes_plugin/configurekubernetesplugin.html

Если разворачивание jenkins осуществлялось с помощью helm, то в кластере kubernetes уже все настроено (service account и прочее).
Чтобы запускать конвейеры в кластере kubernetes достаточно в разделе Cloud настроить:

В поле Name - kubernetes.
В поле Kubernetes URL указать URL, где доступен Kubernetes API,

kubectl cluster-info | grep 'Kubernetes master'

Если кластер развернут с самоподписанными сертификатами - нужно добавить корневой сертификат /etc/kubernetes/pki/ca.crt с master-ноды kubernetes в docker-образ jenkins и прописать в Kubernetes server certificate key - сертификат master-ноды kubernetes. ИЛИ просто поставить галочку Disable https certificate check

cat ~/.kube/config | grep certificate-authority-data: | cut -d: -f2 | tr -d ' ' | base64 -d

нажать Test Connection. В ответ будет Connection test successful
В поле Jenkins URL вставить URL, на котором доступна master-нода Jenkins (внешний URL, на котором доступна master-нода, либо актуальный URL сервиса jenkins в кластере). Если там будет неверный URL, то в логах запускаемых pod'ов будут ошибки типа SEVERE: Failed to connect to http://jenkins.jenkins.svc.cluster.local:8080/tcpSlaveAgentListener/: connect timed out)
В разделе Pod Templates → Containers → EnvVars по-умолчанию прописана единственная переменная - JENKINS_URL. Ей нужно либо дать актуальное значение (внешний URL, на котором доступна master-нода, либо актуальный Jenkins URL сервиса в кластере), либо просто удалить, потому как Jenkins URL в текущей версии задается на уровне плагина.
Также нужно обратить внимание на значение Pod Templates → Labels. Метки должны быть одинаковые в Pod Templates и в конфигурации конвейера.

Проверка работоспособности плагина Jenkins kubernetes

Freestyle project

При использовании типа Freestyle Project пайплайн конфигурируется из web-интерфейса.

На главной страничке web-интерфейса Jenkins жмем New Item.
Даем проекту имя (например - test)
Выбираем тип - Freestyle project.
На вкладке General ставим галку Restrict where this project can be run, а в поле Label Expression вводим метку, указанную в параметре Pod Templates → Labels. Если метка введена корректная, то под полем будет напись примерно такая:

Label TEST is serviced by no nodes and 1 cloud. Permissions or other restrictions provided by plugins may prevent this job from running on those nodes.

А если нод/агентов с такой меткой не найдено, то подсказочка:

There’s no agent/cloud that matches this assignment. Did you mean ‘TEST’ instead of ‘TEST2’?

Затем нужно на вкладке (в разделе) Build кликнуть Add build step и выбрать Execute shell, а затем ввести:

echo 'hello world'

Теперь можно нажать Save и запустить конвейер - Build Now, а затем наблюдать за прогрессом.
Слева в меню появится выполняющееся задание. Можно нажать на него и выбрать Console Output, где будет видно yaml-декларация pod'а и в конце:

Building remotely on jenkins-agent-kdslp (TEST) in workspace /home/jenkins/agent/workspace/test2
[test2] $ /bin/sh -xe /tmp/jenkins5492002065026255241.sh
+ echo hello world
hello world
Finished: SUCCESS

Pipeline

Также можно протестировать работу пайплайна в проектах типа Pipeline. В этом случае конвейер описывается с помощью Jenkinsfile.

На главной страничке web-интерфейса Jenkins жмем New Item.
Даем проекту имя (например - test)
Выбираем тип - Pipeline.

Декларативный стиль

Листаем вниз и в разделе Pipeline выбираем Pipeline Script и вставляем туда скрипт пайплайна в декларативном стиле:

pipeline {
   agent {
    node {
        label 'kube'
    }
   }

   stages {
      stage('Hello') {
         steps {
            echo 'Hello World'
         }
      }
   }
}

Тут важна строка с меткой:

label 'kube'

Эта же метка должна быть в настройках плагина Kubernetes - Pod Templates → Labels.
Однако, можно переопределить параметры контейнера (containerTemplate), указав их в декларации:

pipeline {
   agent {
     kubernetes {
       label 'build-service-pod'
       containerTemplate {
         name 'jnlp'
         image 'jenkins/jnlp-slave:3.27-1'
         ttyEnabled true
        }
      }
    }

   stages {
      stage('Hello') {
         steps {
            echo 'Hello World'
         }
      }

Императивный стиль

Также можно протестировать скрипт в императивном стиле:

node('kube') {
  stage('test') { 
    echo 'Hello World'
  }
}

Тут важна строка с меткой:

node('kube')

Исходники приложения

Я буду тренироваться на тренировочном java-приложении - https://github.com/jenkins-docs/simple-java-maven-app
Нужно взять эти исходники и загрузить на доступный вам git-репозиторий. У меня развернут GitLab и в нем создан пустой проект, но можно обойтись и без сервера git, указывая в качестве адреса локальную папку.

git clone https://github.com/jenkins-docs/simple-java-maven-app
cd simple-java-maven-app/
git remote add autosys https://git.autosys.tk/username/simple-java-maven-app.git
git push -u autosys master

Затем нужно в GitLab сгенерировать для этого проекта Deploy Token (Settings → Repository → Deploy Tokens).

Создание Jenkins-файла

jenkins

anonymous@undisclosed.example.com (Anonymous) — Mon, 18 Nov 2019 08:56:05 +0000

Тут я фиксирую для себя сведения о Jenkins (версии 2 и последующих).

Терминология

Node (узел) - система (физический сервер, виртуальная машина, контейнер), которая способна выполнять задания Jenkins (в том числе и master). В сценарии конвейера под термином node понимается система с установленным агентом (agent).
Master - узел, который хранит настройки конвейеров и управляет запуском задач.
Agent (агент, slave) - программный компонент, работающий на узле, управляемый master'ом и выполняющий задания.
Worker (исполнитель) - сущность внутри агента, которая непосредственно исполняет задание. У одного агента можент быть несколько исполнителей. Количество исполнителей на узле можно настроить.
Stage (этап) - набор действий (шагов) конвейера, объединяемых по смыслу (получение исходников, компиляция, тестирование и т.д.).

Синтаксис конвейеров Jenkins

Jenkins 2 поддерживает два варианта синтаксиса описания конвейеров (Jenkinsfile).

Сценарный синтаксис

Грубо говоря - описание конвейера представляет собой скрипт на языке Groovy.
Сценарный синтаксис более функционален, по сравнению с декларативным и позвоялет создавать максимально гибкие конвейеры.
Визуально сценарный конвейер можно определить по конструкциям вида:

node('worker') {
   stage('Source') {
   ...
   ...

Декларативный синтаксис

Декларативный способ описания конвейера заключается в объявлении состояний и ожидаемых результатов.
Декларативный синтаксис напоминает web-интерфейс с заполняемыми формами. Если каких-то необходимых действий не предусмотрено, то их придется дописывать.
Описание конвейера в декларативном стиле начинается так:

pipeline {
   agent {label:'worker'}
   stages {
      stage('Source') {
      ...
      ...

Синтаксис описания шагов конвейера Jenkins

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

Варианты синтаксиса шагов конвейера

Полный вариант синтаксиса:

git([branch: 'test', url: 'http://github.com/brentlaster/gradle-greetings.git'])

Допускается запись без скобок:

git branch: 'test', url: https://github.com/brentlaster/gradle-greetings.git

Обязательным является только именованный параметр url, поэтому допускается еще более упрощенная запись:

git 'https://github.com/brentlaster/gradle-greetings.git'

Если именованный параметр не требуется, то параметром по умолчанию является объект сценария:

bat ([script: 'echo hi'])

или

bat 'echo hi'

jvm_memory_limits_in_k8s

anonymous@undisclosed.example.com (Anonymous) — Tue, 28 Jan 2025 18:23:08 +0000

Проблема

Нагруженный сервис на Java21 постоянно тыкается в лимит памяти.
Пляски с Xmx что-то не помогают.

Что же делать

Чтобы JVM корректно определяла объем памяти, заданный с помощью k8s mem limit добавляем в опции:
```
-XX:+UseContainerSupport
```
Чтобы не возиться с Xmx, а позволить JVM самостоятельно определить сколько надо - добавляем:
```
-XX:InitialRAMPercentage=50.0
-XX:MaxRAMPercentage=70.0
```
Максимальная цифра 70 - установлена и подтверждена экспериментально. https://stackoverflow.com/a/54076834 и https://stackoverflow.com/questions/65114573/java-memory-settings-in-a-docker-container

В итоге Xmx вычислится сам по формуле

MaxHeapSize = MaxRAM * MaxRAMPercentage / 100% (default MaxRAMPercentage=25)

Важно учитывать, что если задана Xmx, то MaxRAMPercentage не используется.

k3s

anonymous@undisclosed.example.com (Anonymous) — Mon, 17 Aug 2020 18:22:36 +0000

Надо пощупать - https://k3s.io/
K3S - легковесный kubernetes.
Если у стандартного кубера api-server потребляет минимум 400Mb памяти, то тут обещают всего 100.
По идее - для построения однонодового кластера на легкой VPS - самое оно.

k3s_containerd_shim_high_cpu_load

anonymous@undisclosed.example.com (Anonymous) — Fri, 22 Aug 2025 11:52:20 +0000

Проблема

Есть хост Debian 12 с k3s версии - v1.33.3+k3s1 .
На хосте бывает большая нагрузка на проц от процесса containerd-shim-runc-v2
Надо выяснить - что же за контейнер это делает?

Поехали. Смотрим путь до бинарника:

ps -aux | grep 3462
root        3462 91.8  0.1 1240124 14692 ?       Sl   Jul31 28967:46 /var/lib/rancher/k3s/data/8460fc4df8e204d507e141d109ea776ef78412e65121eeb3cf7c67ee581d699f/bin/containerd-shim-runc-v2 -namespace k8s.io -id b9c5ed80dfec2738772a5600fba83c5d83ded282e487687ee2ddc7cda896a0e1 -address /run/k3s/containerd/containerd.sock

Берем id контейнера и смотрим что же это:

ctr c info b9c5ed80dfec2738772a5600fba83c5d83ded282e487687ee2ddc7cda896a0e1

В верхней части вывода будут метки контейнера с именем и прочим.

k8s_actual_container_cpu_memory_consumption

anonymous@undisclosed.example.com (Anonymous) — Wed, 01 Apr 2026 19:03:49 +0000

Актуальное потребление контейнером CPU можно посмотреть так:

kubectl exec -it podname -- cat /sys/fs/cgroup/cpu/cpuacct.usage

Актуальное потребление контейнером памяти можно посмотреть так:

kubectl exec -it podname -- cat /sys/fs/cgroup/memory/memory.usage_in_bytes
kubectl exec -it podname -- cat /sys/fs/cgroup/memory.peak

k8s_ephemeral_storage_consumption

anonymous@undisclosed.example.com (Anonymous) — Thu, 26 Mar 2026 10:01:23 +0000

kubectl get --raw "/api/v1/nodes/ip-172-31-92-255.eu-west-1.compute.internal/proxy/stats/summary" | jq -r '
  .pods[] 
  | select(.["ephemeral-storage"].usedBytes > 1000000) 
  | [
      .podRef.namespace, 
      .podRef.name, 
      ((.["ephemeral-storage"].usedBytes / 1024 / 1024 | floor | tostring) + " MB")
    ] 
  | @tsv' | column -t -s $'\t'

for NODE in `kubectl get no --no-headers=true -o name | cut -d '/' -f2`; do kubectl get --raw "/api/v1/nodes/${NODE}/proxy/stats/summary" | jq -r '
  .pods[] 
  | select(.["ephemeral-storage"].usedBytes > 1000000) 
  | [
      .podRef.namespace, 
      .podRef.name, 
      ((.["ephemeral-storage"].usedBytes / 1024 / 1024 | floor | tostring) + " MB")
    ] 
  | @tsv' | column -t -s $'\t'; done

k8s_hints

anonymous@undisclosed.example.com (Anonymous) — Wed, 01 Apr 2026 20:19:49 +0000

Удалить все подики, которые не Running

k get po -A | grep -v Running | grep -v NAME | awk '{print " -n "$1 " " $2}' | while IFS= read -r line; do kubectl delete po $line ; done

kafka_monitoring

anonymous@undisclosed.example.com (Anonymous) — Wed, 22 Jan 2020 11:25:05 +0000

https://www.datadoghq.com/blog/monitoring-kafka-performance-metrics/
https://kamaok.org.ua/?p=3345

kubernetes

anonymous@undisclosed.example.com (Anonymous) — Thu, 30 Nov 2023 08:03:34 +0000

https://ansilh.com/01-introduction/
https://ansilh.com/15-k8s_from_sratch/

Материалов про kubernetes очень много. В процессе обучения просто я фиксирую для себя то что считаю важным. Это не тутораил и не гайд. Это просто мои заметки.
https://kubernetes.io/docs/reference/kubectl/cheatsheet/

Docker

Сборка контейнера docker

Создаем файл Dockerfile:

FROM node:7
ADD app.js /app.js
ENTRYPOINT ["node", "app.js"]

В одной директории с Dockerfile размещаем файл приложения app.js и собираем:

docker build -t kubia .

Смотрим что контейнер собрался:

docker images

Запуск контейнера вручную в локальном Docker

docker run --name kubia-container -p 8080:8080 -d kubia

В результате будет запущен новый контейнер с именем kubia-container из образа kubia. Контейнер будет отсоединен от консоли (флаг -d), а порт 8080 на локальной машине будет увязан с портом 8080 внутри контейнера.

Список всех запущенных контейнеров docker

docker ps

Получение дополнительной информации о контейнере docker

docker inspect kubia-container

Запуск bash shell внутри существующего контейнера docker

docker exec -it kubia-container bash  
* **-i** убеждается, что STDIN держится открытым для ввода команд в оболочку;
* **-t** выделяет псевдотерминал (TTY).

Остановка и удаление контейнера docker

docker stop kubia-container
docker rm kubia-container

Тегирование образа тегом docker

Образ контейнера может иметь несколько тегов:

docker tag kubia luksa/kubia

Передача образа контейнера docker в хранилище docker hub

docker push luksa/kubia

Запуск образа контейнера docker на другой машине

docker run -p 8080:8080 -d luksa/kubia

Просмотр журналов контейнера docker

docker logs <container_ID>

Запуск приложения в среде kubernetes

kubectl run kubia --image=luksa/kubia --port=8080 --generator=run/v1

kubectl run создаст все необходимые компоненты без необходимости декларировать компоненты с помощью JSON или YAML.
–generator=run/v1 - нужен для того, чтобы текущая версия kubernetes не создавала Deployment, а создала ReplicationController. В результате будет создан Pod с одним контейнером kubia.
При выполнении команды произошло следующее:

команда kubectl создала в кластере новый объект контроллера репликации (ReplicationController)
контроллер репликации создал новый Pod, который планировщик запланировал для одного из рабочих узлов.
Агент Kubelet на этом узле увидел, что модуль был назначен рабочему узлу, и поручил платформе Docker выгрузить указанный образ из хранилища, После скачивания образа платформа Docker создала и запустила контейнер.

Получение списка pods

Список pods в дефолтном namespace:

kubectl get pods

Список pods в заданном namespace:

kubectl -n nsname get po

Список pods во всех неймспейсах:

kubectl get po -A

Вывод списка Pod'ов с дополнительной информацией:

kubectl get pods -o wide

Доступа к приложению в контейнере kubernetes по сети

Для доступа к приложению используются объекты Service. Они привязывают динамически разворачиваемые экземпляры приложения к статичным IP-адресам и портам:

kubectl expose rc kubia --type=LoadBalancer --name kubia-http

В данном случае - создается объект Service с именем kubia-http типа LoadBalancer, который указывает на экземпляры приложения, за которыми следит ReplicatioController (rc) с именем kubia.

Вывод списка kubernetes Services

kubectl get services

или

kubectl get svc

Увеличение количества реплик pod'a

Увеличить количество запущенных реплик Pod'а на контроллере репликации:

kubectl scale rc kubia --replicas=3

Получение полного описания объекта kubernetes

kubectl describe rc kubia

Создание объекта kubernetes с помощью файла описания

kubectl create -f filename.yml

Сеть

Внутри кластера kubernetes между подами (Pods) сеть плоская. Без шлюзов и трансляциий (nat-snat).

Под - Pod

Базовое описание pod'а

apiVersion: v1                     # Версия API
kind: Pod                          # Тип объекта - pod
metadata:                          # Начало секции метаданных
  name: kubia-manual               # имя Pod'a
spec:                              # начало секции спецификации
  containers:                      # начало секции, описывающей контейнеры pod'а
  – image: luksa/kubia             # начало описания первого контейнера. используется образ luksa/kubia 
    name: kubia                    # Имя контейнера в pod'е
    ports:                         # секция портов, используемых приложением в контейнере
    – containerPort: 8080          # номер порта
      protocol: TCP                # используемый протокол

Создание pod'а с помощью файла описания

kubectl create -f kubia-manual.yaml

Удаление pod'ов

kubectl delete po kubia-gpu

Или с помощью селектора по метке:

kubectl delete po -l creation_method=manual

Просмотр логов pod'а

kubectl logs kubia-manual

Если в pod'е больше одного контейнера, то увидеть логи конкретного контейнера можно так:

kubectl logs kubia-manual -c kubia

Маппинг локального порта на порт в pod'е без использования service

Иногда для отладки нужно просто сделать так, чтобы порт pod'а стал доступен на локальной машине. Без создания service. Это делается так:

kubectl port-forward kubia-manual 8888:8080

В результате приложение pod'а (порт 8080) станет доступно на локальной машине на порте 8888.

Метки

Метки могут быть созданы для многих объектов. В примерах рассматриваются pod'ы.

Создание и изменение меток (labels)

Метки позволяют разделять pod'ы по некоторому признаку и обращаться к ним.

kubectl label po kubia-manual creation_method=manual

Метки могут быть прописаны в секции метаданных:

apiVersion: v1
kind: Pod
metadata:
  name: kubia-manual-v2
  labels:
    creation_method: manual
    env: prod

При изменении существующих меток нужно использовать параметр –overwrite.

kubectl label po kubia-manual-v2 env=debug --overwrite

Список всех pod'ов и их меток

kubectl get po --show-labels

Список pod'ов у которых (не)установлены заданные метки

kubectl get po -l creation_method,env
kubectl get po -l '!env',creation_method

Список pod'ов с заданными значениями меток

kubectl get po -l creation_method=manual

Список pod'ов со значениями меток отличными от заданного

kubectl get po -l creation_method!=manual

Установка метки на узел (node) и привязка pod'а к нему

Устанавливаем метку на узел:

kubectl label node gke-kubia-85f6-node-0rrx gpu=true

Описываем привязку в декларации pod'а:

apiVersion: v1
kind: Pod
metadata:
  name: kubia-gpu
spec:
  nodeSelector:
    gpu: "true"                #селектор узла с меткой gpu
  containers:
  – image: luksa/kubia
    name: kubia

Или к узлу с заданным именем:

apiVersion: v1
kind: Pod
metadata:
  name: kubia-gpu
spec:
  nodeSelector:
    kubernetes.io/hostname: "desired.node.hostname"                #селектор узла по его hostname
  containers:
  – image: luksa/kubia
    name: kubia

Пространства имен (namespaces)

Список доступных пространств имен (неймспейсов)

kubectl get ns

Список pod'ов неймспейса

kubectl get po --namespace kube-syste

Создание неймспейсов

kubectl create namespace custom-namespace

Или декларативно с помощью файла yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: custom-namespace

и затем

kubectl create -f custom-namespace.yaml

Создание объектов в заданном неймспейсе

kubectl create -f kubia-manual.yaml -n custom-namespace

Переключение между неймспейсами

kubectl  config  set-context $(kubectl config currentcontext) --namespace custom-namespace

или для быстрого переключения на другое пространство имен можно создать алиас:

alias  kcd='kubectl  config  set-context $(kubectl config currentcontext) --namespace '

прописать его в ~/.bash.rc и затем переключаться между пространствами имен с помощью

kcd some-namespace

Удаление неймспейса со всем содержимым

kubectl delete ns custom-namespace

Удаление содержимого неймспейса с сохранением неймспейса

Удаление pod'ов

kubectl delete po --all

Удаление почти всех ресурсов из неймспейса:

kubectl delete all --all

Глоссарий

Kubernetes - система оркестрации контейнеров docker.
Namespace - это способ логического деления запускаемых в кластере сущностей.
Nodes (node.md): Нода это машина в кластере Kubernetes.
Pods (pods.md): Pod это группа контейнеров с общими разделами, запускаемых как единое целое. Обычно Pod объединет контейнеры, которые всместе выполняют некоторую функцию и не имеют смысла друг без друга. Например, в рамках pod'а процессы разных контейнеров могут общаться друг с другом по сети, используя адреса 127.0.0.1:port. То есть процессы различных контейнеров работают в едином сетевом неймспейсе pod'а.
ReplicaSet - набор экземпляров (реплик) какого-то pod'а. ReplicaSet - это более функциональные Replication Controllers. Сейчас они сосуществуют, но в дальнейшем останутся только ReplicaSet.
Deployment - набор экземпляров pod'а, для которого можно произвести обновление. При обновлении экземпляры будут по одному замещаться новыми версиями (rolling update). Таким образом реализуется zero downtime при обновлениях. Описывается с помощью yml-файла, содержащего спецификации (spec).
Services (services.md): Сервис в Kubernetes это абстракция (описывается yml-файлом) которая определяет логический объединённый набор pod и политику доступа к ним. Например - сервис типа LoadBalancer балансирует нагрузку между подами деплоймента. В простейшем случае - сервис просто пробрасывает порт для доступа к приложению.
Volumes (volumes.md): Volume(раздел) это директория, возможно, с данными в ней, которая доступна в контейнере.
Labels (labels.md): Label'ы это пары ключ/значение которые прикрепляются к объектам, например pod'ам. Label'ы могут быть использованы для создания и выбора наборов объектов.
Kubectl Command Line Interface (kubectl.md): kubectl интерфейс командной строки для управления Kubernetes.
Config Map - yml-файлик, содержащий некоторую конфигурационную информацию (например описание сервера nginx). В дальнейшем, в описании контейнера прописывается volumeMount, с указанием куда смонтируется volume, а также сам Volume, который ссылается на configmap. В результате - содержимое Config Map монтируется в контейнер в файлик в заданную директорию. Инструкции для монтирования содержатся в описании deployment'а или pod'а.

Архитектура

Программыне компоненты Kubernetes можно разделить на две части:

kubelet - компоненты, которые работают на нодах кластера и обеспечивают запуск сервисов на них.
master components - компоненты, необходимые для управления кластером (APIs, scheduler, etc).

Deployment в кластер kubernetes

Для деплоймента в кластер kubernetes нужно описать в docker-файлах сервисы Pod'а. Порядок такой:

создаем docker-файлик.
собираем контейнер
помещаем (push) контейнер в репозиторий контейнеров docker (cloud.docker.com)

В кластере kubernetes создаем namespace (логичекий контейнер для pod'ов, деплойментов (deployments) и т.д.)

kubectl create namespace _name_

Для деплоймента в kubernetes нужно описать три сущности:

Сам deployment, в котором описано какие docker-контейнеры нужно загрузить в pod, сколько таких pod'ов создать, а также какую конфигурацию применить к контейнерам (с помощью ConfigMap'ов).
ConfigMap'ы, которые содержат конфигурационные файлы, необходимые для работы приложений контейнерах. Например - конфигурация nginx для контейнера с nginx.
Service - способ доступа к приложениям в контейнерах (балансировка и проброс портов).

Ход обновления:

клонируем исходник из git.
собираем его.
собираем docker-контейнер с новым тегом версии, содержащий файлы приложения (docker build)
помещаем docker-контейнер в docker registry (docker push)
указываем в деплойменте тег новой версии контейнера.
применяем deployment (kubectl apply) в результате чего обновятся pod'ы.

Для автоматизации с помощью GitLab:

в свойствах проекта создаем Runner
по инструкци устанавливаем gitlab-runner и добавляем пользователя gitlab-runner в группу докера, для того, чтобы раннер мог запускать деплоймент.
после установки gitlab-runner его нужно зарегистрировать (gitlab-runner register)
В конфиге раннера прописываются стадии: build и deploy. build включает в себя создание докерконтейнера, пригодного для деплоя.

Доступ к private registry с паролем

У меня есть private registry на базе Nexus 3. Доступ туда осуществляется по логину-паролю (учетка из Active Directory).
Для того чтобы образы можно было забирать из частного запароленного репозитория нужно:

залогиниться в него:

docker login -u _username_ -p _password_ registry.domain.com

в результате в файлике ~/.docker/config.json окажутся учетные данные, необходимые для работы.
сделать из этого файлика секрет:

kubectl create secret generic registry-credentials -n namespace-name --from-file=.dockerconfigjson=<path_to_home>/.docker/config.json --type=kubernetes.io/dockerconfigjson

и в дальнейшем использовать этот секрет:

apiVersion: v1
kind: Pod
metadata:
  name: private-reg
  namespace: namespace-name
spec:
  containers:
  - name: private-reg-container
    image: <your-private-image>
  imagePullSecrets:
  - name: registry-credentials

Стоит обратить внимание на то, что секреты изолированы на уроне неймспейсов и в каджом неймспейсе должна быть копия секрета для доступа к registry.

Патчинг конфигурации из командной строки

https://stupefied-goodall-e282f7.netlify.com/contributors/devel/strategic-merge-patch/
http://jsonpatch.com/
Иногда нужно отредактировать объекты из скрипта, не запуская редактор.
Для этого у kubectl есть команда patch.

Удаление раздела из конфигурации

kubectl patch PersistentVolume elasticsearch-data --type=json -p='[{"op": "remove", "path": "/spec/claimRef"}]'
kubectl patch PersistentVolume my-pv-name-123465789 -p '{"spec":{"claimRef": null}}'
kubectl patch deployment es-master --type=json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/resources"}]'

Очистка раздела, но не удаление его

kubectl patch PersistentVolume elasticsearch-data  -p '{"spec":{"claimRef":{"$patch": "delete"}}}'

Изменение значения параметра

kubectl -n kubernetes-dashboard patch service kubernetes-dashboard  -p '{"spec":{"type":"NodePort"}}'

в данном случае - редактируем элемент номер 0 списка containers:

kubectl -n elasticsearch patch deployment es-master --type=json -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":1}]'
kubectl -n elasticsearch patch deployment es-master --type=json -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/env/2", "value":{"name": "NUMBER_OF_MASTERS", "value": "1"}}]'

Добавление объекта

kubectl patch pod alpine-correct --type='json' -p='[{"op":"add","path":"/metadata/annotations", "value":{"testone.annotation.io":"test-one","testtwo.annotation.io":"test-two","testthree.annotation.io":"test-three"}}]'

В список:

kubectl -n elasticsearch patch sts es-data --type=json -p='[{"op": "add", "path": "/spec/template/spec/tolerations", "value":[{"effect":"NoSchedule","key":"node.kubernetes.io/rrr","operator":"Exists"}]}]'

Добавляем порт для контейнера в Deployment:

kubectl patch deployment mcs-api --type=json -p='[{"op": "add", "path": "/spec/template/spec/containers/0/ports", "value":[{"containerPort": 5000}]}]'

Патчинг нескольких значений за раз

kubectl patch ns default --type=json -p '[
{"op":"add","path":"/metadata/annotations","value":{"a":"1","b":"2"}},
{"op":"add","path":"/metadata/labels","value":{"c":"3"}}
]'

Отвязать PersistentVolume от заявки PersistentVolumeClaim

kubectl patch PersistentVolume elasticsearch-data --type=json -p='[{"op": "remove", "path": "/spec/claimRef"}]'

Найти все объекты kubernetes во всех неймспейсах

while read -r line; do echo "===============  $line  =================="; kubectl get $line -A; done < <(kubectl api-resources | grep -v NAME | cut -d ' ' -f1)

Удобное редактирование секретов kubernetes

https://github.com/lbolla/kube-secret-editor

sudo apt-get -y install python3-pip python-pip
sudo pip install PyYaml
sudo pip3 install PyYaml
sudo wget https://raw.githubusercontent.com/lbolla/kube-secret-editor/master/kube-secret-editor.py -O /usr/local/bin/kube-secret-editor.py
sudo chmod a+x /usr/local/bin/kube-secret-editor.py
alias kedit-secret="EDITOR=nano KUBE_EDITOR=/usr/local/bin/kube-secret-editor.py kubectl edit secret"
sudo awk -v line='alias kedit-secret="EDITOR=nano KUBE_EDITOR=/usr/local/bin/kube-secret-editor.py kubectl edit secret"' 'FNR==NR && line==$0{f=1; exit} END{if (!f) print line >> FILENAME}' /etc/bash.bashrc

После перелогина (или нового запуска/перезапуска) bash станет доступен alias kedit-secret и отредактировать секрет можно будет так:

kedit-secret -n nsname secret-name

Предоставление ограниченного доступа в кластер с помощью RBAC и сертификатов

https://medium.com/better-programming/k8s-tips-give-access-to-your-clusterwith-a-client-certificate-dfb3b71a76fe
Что нужно понимать.

В кубернетесе НЕ существует базы данных с Пользователями и Группами.
Аутентификация при доступе к кластеру осуществляется с помощью сертификатов. Фактически CN в сертификате - это имя субъекта (пользователя), обращающегося к кластеру. O в сертификате - это имя группы, в которую включе пользователь.
При использовании аутентификации по сертификатам нужно сгенерировать запрос на сертификат, на основании которого кластер может выпустить клиентский сертификат, с некоторым значением полей CN и O.
Привилегии раздаются с помощью ролей. Role - это набор привилегий для субъекта (пользователя или группы).
Для того, чтобы дать права владельцу сертификата нужно создать RoleBinding, которая свяжет роль с тем что написано в сертификате. Если даем права пользователю, то имя пользователя в RoleBinding должно совпадать со значением поля CN в сертификате. Если даем права группе, то имя группы в RoleBinding должно совпадать со значение поля O в сертификате.

Конкретная задача формулируется следующим образом:

Для обращений к api-серверу используется аутентификация по сертикатам.
Разработчику нужно предоставить доступ на просмотр объектов в заданном неймспейсе.
В перспективе аналогичные права понадобятся другим разработчикам. То есть - права будем выдавать на группу.

Скрипт

#!/bin/bash
set -e

KUB_CONTEXT='kubernetes-admin@kubernetes'
KUB_USERNAME='developer-ro'
KUB_USERGROUP='mcs-ro'
#cluster or ns (namespace)
#AUTH_SCOPE='cluster'
AUTH_SCOPE='ns'
# If AUTH_SCOPE = ns then we need namespace name
KUB_NAMESPACE='default'
KUB_ROLE_NAME="${KUB_USERGROUP}-role"
# Comma separated quoted - '"get", "list"'. For all use "*"
KUB_ROLE_APIGROUPS='"*"'
KUB_ROLE_RESOURCES='"*"'
#KUB_ROLE_VERBS='"get", "list"'
KUB_ROLE_VERBS='"*"'

echo "Switching to context '${KUB_CONTEXT}'..."
kubectl config use-context $KUB_CONTEXT

echo "Get Kubernetes Cluster Details..."
CLUSTER_NAME=${KUB_CONTEXT}-cluster
CLUSTER_ENDPOINT=`kubectl get po -n kube-system -o jsonpath="{.items[?(@.metadata.labels.component==\"kube-apiserver\")].metadata.annotations.kubeadm\.kubernetes\.io\/kube-apiserver\.advertise-address\.endpoint}" | cut -d' ' -f 1`
[ -z "$CLUSTER_ENDPOINT" ] && CLUSTER_ENDPOINT=`kubectl cluster-info | grep 'control plane' | awk '{print $NF}' | sed 's/^.*\/\///' | sed -r "s/\x1B\[([0-9]{1,3}(;[0-9]{1,2})?)?[mGK]//g"`
KUB_SYSTEM_TOKEN_SECRET=`kubectl get secret -n kube-system -o name | grep default-token | cut -d'/' -f 2`
CLUSTER_CA=`kubectl get secret -n kube-system $KUB_SYSTEM_TOKEN_SECRET -o jsonpath={".data.ca\.crt"}`

if [ ! -f ./${KUB_USERNAME}.key ]; then
    openssl genrsa -out ./${KUB_USERNAME}.key 4096
fi

echo "Create CSR config file ${KUB_USERNAME}.csr.cnf..."
cat <<EOF > ./${KUB_USERNAME}.csr.cnf
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn

[ dn ]
CN = ${KUB_USERNAME}
O = ${KUB_USERGROUP}

[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
EOF

echo "Create CSR file ${KUB_USERNAME}.csr..."
openssl req -config ./${KUB_USERNAME}.csr.cnf -new -key ${KUB_USERNAME}.key -nodes -out ${KUB_USERNAME}.csr

echo "Create CertificateSigningRequest in ${KUB_CONTEXT} cluster..."
export BASE64_CSR=$(cat ./${KUB_USERNAME}.csr | base64 | tr -d '\n')
kubectl apply -f - <<EOF
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
  name: ${KUB_USERNAME}_csr
spec:
  groups:
  - system:authenticated
  request: ${BASE64_CSR}
  #signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth
EOF

echo "Check if CSR created successfully..."
kubectl get csr ${KUB_USERNAME}_csr

echo "Approving CSR created..."
kubectl certificate approve ${KUB_USERNAME}_csr

echo "Download certificate for user ${KUB_USERNAME} to ${KUB_USERNAME}.crt file..."
kubectl get csr ${KUB_USERNAME}_csr -o jsonpath='{.status.certificate}' | base64 --decode > ${KUB_USERNAME}.crt

if [ "$AUTH_SCOPE" = "cluster" ]; then
echo "Create Cluster Role..."
kubectl apply -f - <<EOF
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: ${KUB_ROLE_NAME}
rules:
- apiGroups: [${KUB_ROLE_APIGROUPS}]
  resources: [${KUB_ROLE_RESOURCES}]
  verbs: [${KUB_ROLE_VERBS}]
EOF

echo "Create Cluster Role Binding for group ${KUB_USERGROUP}..."
kubectl apply -f - <<EOF
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: ${KUB_ROLE_NAME}-${KUB_USERGROUP}
subjects:
- kind: Group
  name: ${KUB_USERGROUP}
  apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: ClusterRole
 name: ${KUB_ROLE_NAME}
 apiGroup: rbac.authorization.k8s.io
EOF
fi

if [ "$AUTH_SCOPE" = "ns" ]; then
kubectl apply -f - <<EOF
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 namespace: ${KUB_NAMESPACE}
 name: ${KUB_ROLE_NAME}
rules:
- apiGroups: [${KUB_ROLE_APIGROUPS}]
  resources: [${KUB_ROLE_RESOURCES}]
  verbs: [${KUB_ROLE_VERBS}]
EOF

kubectl apply -f - <<EOF
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: ${KUB_ROLE_NAME}-${KUB_USERGROUP}
 namespace: ${KUB_NAMESPACE}
subjects:
- kind: Group
  name: ${KUB_USERGROUP}
  apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role
 name: ${KUB_ROLE_NAME}
 apiGroup: rbac.authorization.k8s.io
EOF
fi

CLIENT_CERTIFICATE_DATA=$(kubectl get csr ${KUB_USERNAME}_csr -o jsonpath='{.status.certificate}')
CLIENT_KEY_DATA=$(cat ./${KUB_USERNAME}.key | base64 |  tr -d '\n' )

cat <<EOF > ./kubeconfig_${KUB_USERNAME}_${CLUSTER_NAME}
apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: ${CLUSTER_CA}
    server: https://${CLUSTER_ENDPOINT}
    #insecure-skip-tls-verify: true
  name: ${CLUSTER_NAME}
users:
- name: ${KUB_USERNAME}-${CLUSTER_NAME}
  user:
    client-certificate-data: ${CLIENT_CERTIFICATE_DATA}
    client-key-data: ${CLIENT_KEY_DATA}
contexts:
- context:
    cluster: ${CLUSTER_NAME}
    user: ${KUB_USERNAME}-${CLUSTER_NAME}
  name: ${KUB_USERNAME}-${CLUSTER_NAME}
current-context: ${KUB_USERNAME}-${CLUSTER_NAME}
EOF

kubectl delete certificatesigningrequests ${KUB_USERNAME}_csr

Создание закрытого ключа пользователя и запроса сертификата

Генерируем закрытый ключ:

openssl genrsa -out mike.key 4096

Для генерации закрытого ключа пользователя нужно подготовить файлик mike.csr.cnf, в котором указать имя пользователя и группу, которой мы дадим права:

[ req ]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn

[ dn ]
CN = mike
O = development

[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth

Тут:

CN - имя пользователя
O - имя группы

И дальше генерируем запрос сертификата:

openssl req -config ./mike.csr.cnf -new -key mike.key -nodes -out mike.csr

В итоге - получаем файл запроса сертификата - mike.csr.

Создание сертификата

Теперь нужно отправить запрос в кластер, чтобы на его основе был сгенерирован сертификат.
Создаем переменную окружения, в которую помещаем наш запрос сертификата в кодировке base64:

export BASE64_CSR=$(cat ./mike.csr | base64 | tr -d '\n')

И загоняем манифест в кластер, попутно подставляя в него значение созданной переменной:

kubectl apply -f - <<EOF
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: csr
spec:
  groups:
  - system:authenticated
  request: ${BASE64_CSR}
  usages:
  - digital signature
  - key encipherment
  - server auth
  - client auth
EOF

Убеждаемся, что запрос создан:

$ kubectl get csr
NAME      AGE   REQUESTOR          CONDITION
csr       31s   kubernetes-admin   Pending

И выпускаем сертификат:

kubectl certificate approve csr

Если при аппруве появляется ошибка типа:

error: no kind "CertificateSigningRequest" is registered for version "certificates.k8s.io/v1" in scheme "k8s.io/kubectl/pkg/scheme/scheme.go:28"

то скорее всего делл в том, что в кластере несколько версий API для ресурса certifictes, либо версия kubectl отстает от версии кластера. Проверяем это:

kubectl get apiservice | grep certificates
kubectl version --short

Если там две версии API для ресурса certifictes, то удаляем старую, а также обновляем kubectl при необходимости:

kubectl delete apiservice v1beta1.certificates.k8s.io

А теперь - извлекаем его:

kubectl get csr csr -o jsonpath='{.status.certificate}' | base64 --decode > mike.crt

Создаем роль для ограничения прав в неймспейсе

kubectl apply -f - <<EOF
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 namespace: development
 name: dev
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list"]
EOF

Даем права пользователю или группе

Привязываем пользователя к роли (по имени):

kubectl apply -f - <<EOF
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: dev
 namespace: development
subjects:
- kind: User
  name: mike
  apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role
 name: dev
 apiGroup: rbac.authorization.k8s.io
EOF

Либо к группе:

kubectl apply -f - <<EOF
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: dev
 namespace: development
subjects:
- kind: Group
  name: development
  apiGroup: rbac.authorization.k8s.io
roleRef:                             
 kind: Role                          
 name: dev
 apiGroup: rbac.authorization.k8s.io 
EOF

Создание файлика kubeconfig

Теперь для доступа к кластеру пользователю нужен файл, конфигурации, который будет содержать ссылку на api-сервер кластера, а также сертификаты.
Зададим значения переменных, которые будут подставлены в шаблон:

export USER="mike"
export CLUSTER_NAME=$(kubectl config view --minify -o jsonpath={.clusters[0].name})
export CLUSTER_ENDPOINT=$(kubectl config view --raw -o json | jq -r ".clusters[] | select(.name == \"$CLUSTER_NAME\") | .cluster.server")
export CLIENT_CERTIFICATE_DATA=$(kubectl get csr mycsr -o jsonpath='{.status.certificate}')
export CLIENT_KEY_DATA=$(cat ./mike.key | base64 | tr -d '\n')
export CLUSTER_CA=$(kubectl get secret -o jsonpath="{.items[?(@.type==\"kubernetes.io/service-account-token\")].data['ca\.crt']}")

И создадим файлик, в который подставим эти значения параметров:

cat <<EOF > kubeconfig
apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: ${CLUSTER_CA}
    server: ${CLUSTER_ENDPOINT}
    #insecure-skip-tls-verify: true
  name: ${CLUSTER_NAME}
users:
- name: ${USER}
  user:
    client-certificate-data: ${CLIENT_CERTIFICATE_DATA}
    client-key-data: ${CLIENT_KEY_DATA}
contexts:
- context:
    cluster: ${CLUSTER_NAME}
    user: ${USER}
  name: ${USER}-${CLUSTER_NAME}
current-context: ${USER}-${CLUSTER_NAME}
EOF

Предоставление ограниченного доступа в кластер с помощью RBAC и Service Accounts

# https://documentation.commvault.com/v11/essential/129223_creating_kubernetes_cluster_admin_service_account_for_commvault.html

#!/bin/bash
set -e

KUB_CONTEXT='anima-lightning2-dev'
KUB_USERNAME='dashboard-ro'
KUB_NAMESPACES=('lightning-dev' 'lightning-tst')
######KUB_USERGROUP='mcs-ro'
#cluster or ns (namespace)
#AUTH_SCOPE='cluster'
AUTH_SCOPE='ns'
# If AUTH_SCOPE = ns then we need namespace name
#KUB_NAMESPACES=('default')

# Comma separated quoted - '"get", "list"'. For all use "*"
KUB_ROLE_APIGROUPS='"*"'
KUB_ROLE_RESOURCES='"*"'
#KUB_ROLE_VERBS='"get", "list"'
KUB_ROLE_VERBS='"get", "list"'

echo "Switching to context '${KUB_CONTEXT}'..."
kubectl config use-context $KUB_CONTEXT

echo "Get Kubernetes Cluster Details..."
CLUSTER_NAME=${KUB_CONTEXT}-cluster
CLUSTER_ENDPOINT=`kubectl get po -n kube-system -o jsonpath="{.items[?(@.metadata.labels.component==\"kube-apiserver\")].metadata.annotations.kubeadm\.kubernetes\.io\/kube-apiserver\.advertise-address\.endpoint}" | cut -d' ' -f 1`
[ -z "$CLUSTER_ENDPOINT" ] && CLUSTER_ENDPOINT=`kubectl cluster-info | grep 'control plane' | awk '{print $NF}' | sed 's/^.*\/\///' | sed -r "s/\x1B\[([0-9]{1,3}(;[0-9]{1,2})?)?[mGK]//g"`
KUB_SYSTEM_TOKEN_SECRET=`kubectl get secret -n kube-system -o name | grep default-token | cut -d'/' -f 2`
CLUSTER_CA=`kubectl get secret -n kube-system $KUB_SYSTEM_TOKEN_SECRET -o jsonpath={".data.ca\.crt"}`

kubectl create serviceaccount ${KUB_USERNAME}-sa -n kube-system || true

echo "Create ClusterRole '${KUB_USERNAME}-ns-cluster-role' to List Namespaces..."
kubectl apply -f - <<EOF
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: ${KUB_USERNAME}-ns-cluster-role
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list"]

EOF

echo "Create Cluster Role Binding for group '${KUB_USERNAME}-ns-cluster-role' to List Namespaces..."
kubectl apply -f - <<EOF
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: ${KUB_USERNAME}-ns-cluster-rolebinding
subjects:
- kind: ServiceAccount
  name: ${KUB_USERNAME}-sa
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: ${KUB_USERNAME}-ns-cluster-role
  apiGroup: rbac.authorization.k8s.io
EOF

if [ "$AUTH_SCOPE" = "ns" ]; then
for KUB_NAMESPACE in ${KUB_NAMESPACES[@]}; do
kubectl create ns ${KUB_NAMESPACE} || true

echo "Creating Role - '${KUB_USERNAME}-role' in the namespace '${KUB_NAMESPACE}'..."
kubectl replace -f - <<EOF
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: ${KUB_NAMESPACE}
  name: ${KUB_USERNAME}-role
rules:
- apiGroups: [${KUB_ROLE_APIGROUPS}]
  resources: [${KUB_ROLE_RESOURCES}]
  verbs: [${KUB_ROLE_VERBS}]
EOF

echo "Creating RoleBinding for the '${KUB_USERNAME}-role' in the namespace '${KUB_NAMESPACE}'..."
kubectl replace -f - <<EOF
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: ${KUB_USERNAME}
  namespace: ${KUB_NAMESPACE}
subjects:
- kind: ServiceAccount
  name: ${KUB_USERNAME}-sa
  namespace: kube-system
roleRef:
  kind: Role
  name: ${KUB_USERNAME}-role
  apiGroup: rbac.authorization.k8s.io
EOF
done
fi

if [ "$AUTH_SCOPE" = "cluster" ]; then
echo "Creating ClusterRole '${KUB_USERNAME}-cluster-role' to access resources..."
kubectl apply -f - <<EOF
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: ${KUB_USERNAME}-cluster-role
rules:
- apiGroups: [${KUB_ROLE_APIGROUPS}]
  resources: [${KUB_ROLE_RESOURCES}]
  verbs: [${KUB_ROLE_VERBS}]
EOF

echo "Create Cluster Role Binding for group '${KUB_USERNAME}-cluster-role' to access resources..."
kubectl apply -f - <<EOF
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: ${KUB_USERNAME}-cluster-rolebinding
subjects:
- kind: ServiceAccount
  name: ${KUB_USERNAME}-sa
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: ${KUB_USERNAME}-cluster-role
  apiGroup: rbac.authorization.k8s.io
fi
EOF
fi

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: ${KUB_USERNAME}-sa-token
  namespace: kube-system
  annotations:
    kubernetes.io/service-account.name: ${KUB_USERNAME}-sa
type: kubernetes.io/service-account-token
EOF

SA_TOKEN=`echo "kubectl get secrets -n kube-system -o jsonpath=\"{.items[?(@.metadata.annotations['kubernetes\\.io/service-account\\.name']=='${KUB_USERNAME}-sa')].data.token}\" | base64 --decode" | /bin/bash`

cat <<EOF > ./kubeconfig_${KUB_USERNAME}_${CLUSTER_NAME}
apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: ${CLUSTER_CA}
    server: https://${CLUSTER_ENDPOINT}
    #insecure-skip-tls-verify: true
  name: ${CLUSTER_NAME}
users:
- name: ${KUB_USERNAME}-${CLUSTER_NAME}
  user:
    token: ${SA_TOKEN}
contexts:
- context:
    cluster: ${CLUSTER_NAME}
    user: ${KUB_USERNAME}-${CLUSTER_NAME}
  name: ${KUB_USERNAME}-${CLUSTER_NAME}
current-context: ${KUB_USERNAME}-${CLUSTER_NAME}
EOF

Bash-скрипты в init-контейнерах при деплойменте с помощью helm

В чарте в директории files я имею просто скрипт, который должне запуститься в init-контейнере.
Я поменщаю этот скрипт в секрет с помощью такого манифеста:

apiVersion: v1
kind: Secret
metadata:
  name: files
type: Opaque
data: 
{{ (.Files.Glob "files/*").AsSecrets | indent 2 }}

В деплойменте я запускаю init-контейнер, в котором монтируется секрет с этим скриптом и выполняется этот скрипт:

...
      initContainers:
      - name: copy-files
        image: docker.rdleas.ru/busybox
        command:
        - "sh"
        - "-c"
        - "cp /tmp/files/init-script.sh /tmp/ && chmod u+x /tmp/init-script.sh && /tmp/init-script.sh"
        volumeMounts:
        - name: files
          mountPath: /tmp/files/
...
      volumes:
      - name: files
        secret:
          secretName: files

то есть мне надо сделать скрипт исполняемым (дать соотвествующие разрешения), но смонтирован он как read-only, поэтому я предварительно копирую его. А после того, как разрешено его исполнение - запускаю скрипт.

Обновление сертификатов

https://github.com/kubernetes/kubeadm/issues/581#issuecomment-471575078
Обновление сертификатов (даже просроченных) на мастерах.
Проверить валидность:

kubeadm certs check-expiration

Обновить все сразу:

kubeadm certs renew all

Обновить по одному:

kubeadm certs renew apiserver
kubeadm certs renew apiserver-kubelet-client
kubeadm certs renew front-proxy-client
kubeadm certs renew admin.conf

Просроченный сертификат ноды в kubelet.conf

Проблема

На ноде не стартует kubelet, при старте в /var/log/syslog такое:

Nov 22 15:10:08 kub-master01 systemd[1]: Started Kubernetes systemd probe.
Nov 22 15:10:08 kub-master01 kubelet[6927]: I1122 15:10:08.032987    6927 server.go:411] Version: v1.19.3
Nov 22 15:10:08 kub-master01 kubelet[6927]: I1122 15:10:08.033277    6927 server.go:831] Client rotation is on, will bootstrap in background
Nov 22 15:10:08 kub-master01 kubelet[6927]: E1122 15:10:08.035302    6927 bootstrap.go:265] part of the existing bootstrap client certificate is expired: 2020-11-20 08:19:12 +0000 UTC
Nov 22 15:10:08 kub-master01 kubelet[6927]: F1122 15:10:08.035329    6927 server.go:265] failed to run Kubelet: unable to load bootstrap kubeconfig: stat /etc/kubernetes/bootstrap-kubelet.conf: no such file or directory

Проблема усугубляется тем, что это однонодовый кластер и просто сделать kubeadm join не выйдет.

Диагностика

Вот такой конвейер позвоялет увидеть дату окончания сертификата ноды, который хранится в kubelet.conf.

cat /etc/kubernetes/kubelet.conf  | grep 'client-certificate-data:' | cut -d':' -f2 | sed 's/\s*//g' | base64 -d | openssl x509 -noout -enddate
notAfter=Nov 20 08:19:12 2020 GMT

Обновляем сертификат

Извлекаем сертификат:

cat /etc/kubernetes/kubelet.conf  | grep 'client-certificate-data:' | cut -d':' -f2 | sed 's/\s*//g' | base64 -d > ./node.crt.pem

Извлекаем ключ:

cat /etc/kubernetes/kubelet.conf  | grep 'client-key-data:' | cut -d':' -f2 | sed 's/\s*//g' | base64 -d > ./node.key.pem

Генерируем запрос:

openssl x509 -x509toreq -signkey ./node.key.pem -in ./node.crt.pem -out ./node.csr

Проверяем запрос:

openssl req -text -noout -verify -in ./node.csr

Создаем новый сертификат

openssl x509 -req -in node.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -set_serial 10 -out ./new_node.crt.pem

Кодируем новый сертификат в base64

base64 -w 0 ./new_node.crt.pem

И затем подставляем в поле client-certificate-data: в файлике /etc/kubernetes/kubelet.conf

Kubernetes LDAP Auth

LDAP-аутентификацию к кластеру kubernetes можно прикрутить с помощью различных средств, но все они используют один подход и схожие по назначению компоненты:

Служба каталога с поддрежкой протокола LDAP. Например - Active Directory
Провайдер OpenID Connect, с которым взаимодействует кластер kubernetes. OIDC - это приложение, которое аутентифицирует пользователей в LDAP и сообщает кластеру Kubernetes сведения о нем, чтобы kubernetes мог сгенерировать сертификат.
Некое web-приложение, с которым взаимодействует пользователи. Оно перенапрявляет пользователя на OpenID Connector, получает от кластера kubernetes сертификат и генерирует конфиг для kubectl.

OIDC Providers

Dex
Keycloak

WebApps

Kuberos - https://github.com/negz/kuberos (не поддерживается с 2019 года)
GangWay
Dex K8s Authenticator

Keycloak + kubelogin

Мне понравился такой вариант - Keycloak в качестве OIDC-провайдера и kubelogin в качестве способа получения токена.

Настройка client в keycloak

В параметры клиента в keycloak в valid redirect uris нужно прописать http://localhost:8000 (или *)

Настройка кластера kubernetes

На каждой мастер-ноде редактируем файл /etc/kubernetes/manifests/kube-apiserver.yaml и добавляем туда такие параметры:

    - --oidc-ca-file=/etc/ssl/certs/RDLeas_Root_CARDleas-SRV-DC02-CA.pem
    - --oidc-client-id=kubernetes
    - --oidc-groups-claim=groups
    - --oidc-issuer-url=https://sso.rdleas.ru/auth/realms/rdleas
    - --oidc-username-claim=email

Редактируем Configmap и также добавляем туда эти параметры:

kubectl edit cm -n kube-system kubeadm-config

data:
  ClusterConfiguration: |
    apiServer:
      ...
      extraArgs:
        authorization-mode: Node,RBAC
        oidc-ca-file: /etc/ssl/certs/RDLeas_Root_CARDleas-SRV-DC02-CA.pem
        oidc-client-id: kubernetes          
        oidc-groups-claim: groups
        oidc-issuer-url: https://sso.rdleas.ru/auth/realms/rdleas
        oidc-username-claim: email

Настройка клиентской машины

Устанавливаем плагин kubelogin.
Скачиваем бинарник https://github.com/int128/kubelogin/releases
Извлекаем его куда-то в $PATH, например - /usr/local/bin/kubelogin

В ~/.kube/config прописываем пользователя:

- name: oidc
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - get-token
      - --oidc-issuer-url=https://sso.rdleas.ru/auth/realms/rdleas
      - --oidc-client-id=kubernetes
      command: kubelogin
      env: null
      provideClusterInfo: false

И контекст с его участием:

- context:
    cluster: sbl-apps-dev
    user: oidc
  name: sbl-apps-dev-oidc

Назначение привилегий в кластере

Название групп в манифестах должно быть точно таким же как и в токене. В моей инсталляции в начале названия группы есть слеш.
Права на неймспейс (в даннос лучае - default) выдаем так:

NAMESPACE=default
GROUP='/Kubernetes_Default_Ns_Admins'
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ${NAMESPACE}-admins
  namespace: ${NAMESPACE}
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - '*'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubernetes-${NAMESPACE}-namespace-admins
  namespace: ${NAMESPACE}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ${NAMESPACE}-admins
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: ${GROUP}
EOF

Права на весь кластер выдаем так:

GROUP='/Kubernetes_Cluster_Admins'
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admins-oidc
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: ${GROUP}
EOF

Разрешение проблем

Поглядеть текущий токен можно так:

kubelogin get-token --oidc-issuer-url=https://sso.rdleas.ru/auth/realms/rdleas --oidc-client-id=kubernetes

Расшифровать его (и увидеть список групп в нем) можно тут: https://jwt.io/

invalid bearer token, oidc: email not verified

В логе kube-apiserver ошибка

Unable to authenticate the request due to an error: [invalid bearer token, oidc: email not verified]

В токене такое:

"email_verified": false

Нужно выключить верификацию email на keycloak (поле email_verified не будет появляться в токене).
В Keycloak идем: Client Scopes → Email → Mappers и удаляем Email verified.

Поглядеть подробный лог можно так:

kubectl --token=$token --server=https://192.168.1.2:6443 --insecure-skip-tls-verify get po --v=10

Dex + Dex K8s authenticator

https://uni.dtln.ru/digest/autentifikaciya-v-kubernetes-s-pomoshchyu-dex-prikruchivaem-ldap
https://habr.com/ru/post/436238/
https://habr.com/ru/company/dataline/blog/497482/
https://github.com/mintel/dex-k8s-authenticator

Keycloak + Gangway

https://github.com/heptiolabs/gangway

Dex + GangWay

https://github.com/alexbrand/gangway-dex-tutorial

JWT-Токены для аутентификации

https://github.com/negz/kubehook

Ссылки

https://www.digitalocean.com/community/tutorials/how-to-create-a-kubernetes-cluster-using-kubeadm-on-ubuntu-18-04

Отмена удаления PersistentVolume

Если так случайно вышло, что вы удалили PersistentVolume, то не отчаивайтесь! Он будет находитьтся в состоянии Terminating до тех пор, пока существуют pod, куда он смонтирован и PersistentVolumeClaim, которая породила этот PV и удаление можно отменить.
На помощь приходит специальная утилитка: https://github.com/jianz/k8s-reset-terminating-pv

git clone https://github.com/jianz/k8s-reset-terminating-pv.git
cd k8s-reset-terminating-pv
go build -o resetpv

Собранный бинарник: resetpv.tar.gz
Заходим на мастер-ноду, архивируем сертификаты и смотрим какой сертификат за что отвечает:

ssh user@master-node
sudo -H tar -cvzf ~/etcd-pki.tar.gz /etc/kubernetes/pki/etcd
sudo docker  ps --no-trunc | grep etcd
exit

В выводе среди всего прочего будет такое:

--advertise-client-urls=https://10.77.68.1:2379
--cert-file=/etc/kubernetes/pki/etcd/server.crt
--key-file=/etc/kubernetes/pki/etcd/server.key
--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt

В вашей инсталляции имена, пути и порты могут быть иными.
И забираем с мастер-ноды кластера архив с сертификатами, которые необходимы для подключения к etcd кластера:

scp user@master-node:/home/user/etcd-pki.tar.gz ./
tar -xvf ./etcd-pki.tar.gя
mv ./etc/kubernetes/pki/etcd/* ./

И дальше применяем утилиту:

./resetpv --etcd-ca ./ca.crt --etcd-cert ./server.crt --etcd-key ./server.key --etcd-host 10.77.68.1 --etcd-port 2379 pv-name

Если вдруг так вышло, что вы удалили все PV в кластере (как я - хотел удалить pvc в неймспейсе но просто опечатался и вместо pvc ввел pv):

kubectl delete -n namespace pv --all

то чтобы отменить удаление всех PV делаем так:

PVs=`kubectl get pv | grep Terminating | awk '{print $1}' | grep -v NAME`
for pv in $PVs; do ./resetpv --etcd-ca ./ca.crt --etcd-cert ./server.crt --etcd-key ./server.key --etcd-host 10.77.68.1 --etcd-port 2379 $pv; done

Распределить поды деплоймента по разным нодам кластера

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service
  labels:
    app: my-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-service
  template:
    metadata:
      labels:
        app: my-service
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: my-service

Либо:

      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - {{ .Release.Name }}-logstash
            topologyKey: kubernetes.io/hostname

Разница между этими подходами описана тут: https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/#comparison-with-podaffinity-podantiaffinity
В двух словах - podAntiAffinity более старый и простой способ и в будущем - предпочтительно пользоваться topologySpreadConstraints, который поддерживает не только распределение по нодам, но и по зонам доступности в облаках.

Headless Services для Stafullset

И другие вопросы про то как давать доступ к индивидуальным подам реплик стейтфуллсетов.
https://www.tigera.io/blog/exposing-statefulsets-in-kubernetes/

Обычно сервисы используются в k8s для балансировки запросов на все реплики микросервиса, однако, в слуаче со statefull-приложениями может понадобиться доступ к конкретной реплике. Для этого в k8s существуют Statefullset'ы и связанные с ними Headless-сервисы.
Что такое Statefullset - это способ создать набор именованных реплик сервиса, каждая из которых будет сохранять свое имя и после перезапуска.
Что такое Headless Service - это сервис, который НЕ имеет адреса в кластере (ClusterIP: None) и НЕ выполняет балансировку подключний по эндпоинтам, а просто является списком эндпоинтов для именованных реплик, управляемых Statefullset'ом. А для доступа к именованным репликам в DNS кластера генерируются имена:

<StatefulSet>-<Ordinal>.<Service>.<Namespace>.svc.cluster.local

например:

app-0.myapp.default.svc.cluster.local.

Вопрос - а как же можно опубликовать именованную реплику в составе Statefullset'а, например через Ingress?? Ведь для этого надо как-то сослаться на сервис, который будет связан с портом на конкретной реплике!
Все просто - каждый под, управляеый Statefullset'ом имеет уникальну метку (примерно такую - statefulset.kubernetes.io/pod-name: app-0 ), которую можно использовать в качестве селектора в сервисе:

apiVersion: v1
kind: Service
metadata:
  name: app-0
spec:
  type: LoadBalancer
  selector:
    statefulset.kubernetes.io/pod-name: app-0
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

Как скопировать секрет из одного неймспейса в другой

kubectl get secret my-tlssecret --namespace=nginx-ns -o yaml | sed 's/namespace: .*/namespace: default/' | kubectl apply -f -

Список и спецификации СustomResourceDefinitions

Список существующих в кластере Сustom Resource Definitions

kubectl get customresourcedefinitions

или

kubectl get crd

ну и посмотреть спецификацию:

kubectl describe crd <crd_name>

Плавный рестарт подиков в деплойментах

В общем случае плавно рестартить можно так:

kubectl rollout restart deployment my-app

А для всех деплойментов в неймспейсе:

ns=namespacename; for deployment in `kubectl get deployment -n ${ns} | grep -v NAME | awk '{print $1}'`; do kubectl -n ${ns} rollout restart deployment ${deployment}; done

Плавный рестарт всех подиков во всех деплойментах во всех неймспейсах:

for ns in `kubectl get ns | grep -v NAME | awk '{print $1}'`; do for deployment in `kubectl get deployment -n ${ns} | grep -v NAME | awk '{print $1}'`; do kubectl -n ${ns} rollout restart deployment ${deployment}; done; done

/etc/resolve.conf в подиках

При старте подика формируется файл /etc/resolve.conf в котором прописано как будут резолвиться имена.
Важным параметром является options ndots:5
Этот параметр задает то, сколько МИНИМУМ точек должно быть точек в имени, чтобы рассмастривать его как FQDN и не пытаться искать это имя с суффиксами из search.
Изменить его значение можно с помощью специального раздела конфигурации подика:

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsConfig:
    options:
      - name: ndots
        value: "1"

kubernetes_backup

anonymous@undisclosed.example.com (Anonymous) — Wed, 19 Jan 2022 18:32:27 +0000

kubernetes_backup_recovery_fd.zip

kubernetes_dns_reply_from_unexpected_source

anonymous@undisclosed.example.com (Anonymous) — Wed, 02 Jun 2021 08:47:36 +0000

В кластере запущенные приложения перестали получать корректные ответы от DNS.
Диагностируем. Запускаем pod с dnsutils:

kubectl run dnsutils --image=gcr.io/kubernetes-e2e-test-images/dnsutils:1.3 -- sleep 3600

Заходим в нему в консольку:

kubectl exec -it dnsutils -- /bin/sh

И проверяем:

# nslookup kubernetes.default
;; reply from unexpected source: 10.244.0.178#53, expected 10.96.0.10#53

НЕ РАБОТАЕТ! Оказалось, что после замены CRI (с docker на containerd) скорее всего в результате удаления docker, перестал загружаться модуль ядра br_netfilter.
Чтобы просто заставить работать нужно сделать так:

Debian
modprobe br_netfilter

CentOS
echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables

А чтобы модуль загружался автоматически при загрузке хоста нужно сделать так:

echo 'br_netfilter' | sudo tee -a /etc/modules

kubernetes_docker_deprecating

anonymous@undisclosed.example.com (Anonymous) — Sat, 23 Apr 2022 17:34:26 +0000

https://kruyt.org/migrate-docker-containerd-kubernetes/

Проверяем, что у нас всё хорошо с containerd. Смотрим его неймспейсы. Там должен быть неймспейс moby - неймспейс, в котором запускает контейнеры docker:

sudo ctr namespace list
sudo ctr --namespace moby container list

Если неймспейс и контейнеры видны - значит все хорошо. Кордоним и дрейним ноду:

kubectl cordon kub
kubectl drain kub --delete-emptydir-data --ignore-daemonsets

Останавливаем сервисы:

systemctl stop kubelet
systemctl stop docker

Удаляем докер:

sudo apt-get purge docker.io

Генерим дефолтный конфиг и убеждаемся, что плагин cri не входит в список отключенных в конфиге containerd:

sudo mkdir -p /etc/containerd/
sudo containerd config default | sudo tee -a /etc/containerd/config.toml
containerd config dump | grep disabled_plugins

А если он там есть, то включаем cri (удаляем его из списка отключенных). Для этого комментируем строку в файле /etc/containerd/config.toml:

#disabled_plugins = ["cri"]

Включаем containerd в конфиг kubelet. То есть добавляем параметры

--container-runtime=remote --container-runtimeendpoint=unix:///run/containerd/containerd.sock

к строке с параметрами запуска kubelet в файле /var/lib/kubelet/kubeadm-flags.env. В итоге содержимое файла в моем случае стало таким:

KUBELET_KUBEADM_ARGS="--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.2 --resolv-conf=/run/systemd/resolve/resolv.conf --container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock"

Всё. теперь можно перезагрузить ноду.
После перезагрузки у меня kubelet не завелся с ошибкой:

Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag.
Flag --resolv-conf has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag.

В итоге:

В /var/lib/kubelet/kubeadm-flags.env осталось вот что:

KUBELET_KUBEADM_ARGS="--network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.2 --container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock"

или

KUBELET_KUBEADM_ARGS="--fail-swap-on=false --pod-infra-container-image=k8s.gcr.io/pause:3.4.1 --container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock"

Параметры –resolv-conf и –cgroup-driver переехали в /var/lib/kubelet/config.yaml:
```
resolvConf: /run/systemd/resolve/resolv.conf
cgroupDriver: systemd
```

После удаления docker многие пакеты, в том числе и containerd, будут считаться ненужными и могут быть автоматически удалены! Поэтому - их нужно переустановить вручную:

apt-get install bridge-utils cgroupfs-mount containerd git patch pigz runc

Также - нужно прописать в свойствах ноды путь до сокета нового CRI. Проверить что там прописано сейчас можно так:

kubetl get no -o yaml | grep cri

И там должен быть путь до сокета containerd:

kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock

В моем случае - некорректное значение этого параметра (он указывал на docker-shim) приводило к тому что в логах kubelet service было много такого:

Apr 23 16:57:45 kub kubelet[771273]: E0423 16:57:45.583662  771273 cri_stats_provider.go:669] "Unable to fetch container log stats" err="failed to get fsstats for \"/var/log/pods/elk_elk-es-data-0_67a13965-df24-4d48-9abb-e6670f35acab/elasticsearch/4.log\": no such file or directory" containerName="elasticsearch"

Кажется, что по пути до сокета CRI определяется его тип и путь до логов. В моем случае - файл который пытался обнаружить kubelet был символической ссылкой на файл в /var/lib/docker, а после зуказания корректного пути до сокета в свойствах ноды - всё встало на свои места!
Ну и анкордоним ноду:

kubectl uncordon kub

Проблемы

не запускается pod eck

После перехода на containerd перестал запускаться под ElasticSearch Operator for kubernetes - eck с такой ошибкой:

{"log.level":"error","@timestamp":"2021-06-01T20:31:34.184Z","log.logger":"manager","message":"Error setting GOMAXPROCS","service.version":"1.1.1-f13b6d26","service.type":"eck","ecs.version":"1.4.0","error":"invalid format for CGroupSubsys: \"12:freezer:/kubepods-burstable-podf1fe3a11_2795_4c46_8eb6_a1929f4a53b5.slice:cri-containerd:96c7b19a81ff398e19131d816fb6de264e53499e5ad9b5a563f879cf1b37390c\"","error.stack_trace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-logr/zapr@v0.1.0/zapr.go:128\ngithub.com/elastic/cloud-on-k8s/cmd/manager.execute\n\t/go/src/github.com/elastic/cloud-on-k8s/cmd/manager/main.go:188\ngithub.com/elastic/cloud-on-k8s/cmd/manager.glob..func1\n\t/go/src/github.com/elastic/cloud-on-k8s/cmd/manager/main.go:74\ngithub.com/spf13/cobra.(*Command).execute\n\t/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:830\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\t/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:914\ngithub.com/spf13/cobra.(*Command).Execute\n\t/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:864\nmain.main\n\t/go/src/github.com/elastic/cloud-on-k8s/cmd/main.go:27\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:203"}

Гугление вывело сюда: https://discuss.elastic.co/t/elastic-operator-0-crashloopbackoff/267736/3
Нужно подредактировать конфиг containerd. В файлике /etc/containerd/config.toml для пары плагинов нужно выставить параметры:

version = 2
[plugins]
  [plugins."io.containerd.grpc.v1.cri"]
   [plugins."io.containerd.grpc.v1.cri".containerd]
      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
          runtime_type = "io.containerd.runc.v1"
          [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
            SystemdCgroup = true

В кластере не работает DNS

kubernetes_dns_reply_from_unexpected_source

Диагностика с помощью crictl

Создаем файлик /etc/crictl.yaml:

runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 10
debug: true

И дальше можем делать то что написано тут: https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/
смотреть поды:

crictl pods

Смотреть контейнеры:

crictl ps -a

И логи контейнеров (это полезно, когда не работает инфрастурктура кубера kube-api или etcd):

crictl logs {Container_ID}

logrotate_in_kubernetes

anonymous@undisclosed.example.com (Anonymous) — Tue, 11 Aug 2020 09:13:06 +0000

mainpage

anonymous@undisclosed.example.com (Anonymous) — Tue, 22 Oct 2019 07:52:14 +0000

message_to_ms_teams_channel_from_bash_with_curl

anonymous@undisclosed.example.com (Anonymous) — Wed, 23 Jul 2025 08:03:33 +0000

Задача

Надо отправлять сообщения в канал MS Teams из CI/CD через MS Graph API. Тo есть из bash-скрипта.

Что для этого нужно

Зарегать приложение на портале https://entra.microsoft.com .
Дать приложению права
Сгенерировать Authorizaton Code для того, чтобы получить API токен и refresh токен. Authorizaton Code одноразовый, генерируется в интерактивном режиме с аутентификацией пользователя и нужен для получения API-токена (короткоживущий для отправки сообщений) и refresh-токена (живет долго - 90 дней, для получения API-токенов).
Получить team id (идентификатор организации в MS Teams), получить channel id.
Сверстать сообщение и отправить.

Регистрация приложения

идем на https://entra.microsoft.com
Дальше - Identity → App Registrations
В настройках приложения в Overview смотрим Application (client) ID и сохраняем.
В Authentication добавляем Redirection URL - http://localhost/myapp
В Certificates & Secrets добавляем Secret и сохраняем его ID и Secret
В API Permissions жмем Add Permission → Microsoft Graph и добавляем Delegated → ChannelMessage.Send

Немного пояснений:

MS Graph API не позволяет отправлять сообщения от имени приложения (то есть использовать статичный секрет для аутентификации). В итоге - используется Delegated привилегия ChannelMessage.Send, то есть приложение от имени пользователя получает токен и отправляет сообщения. Если живой пользователь не должен быть в этой схеме, то MS предлягает использовать служебные учетки - то есть фактически виртуальных бесправных пользователей.

Получение Authorization Code

Это происходит в интерактивном режиме в браузере.
ВНИМАНИЕ - примерно в середтне июля 2025 у MS сменился алгоритм и теперь вместо group_id нужно использовать tenant_id
Получаем нужные данные:

tenant_id - напротив любого канала в MS Teams нажимаем три точки и жмем Get link to channel. В этой ссылке будет параметр - tenantId. Это он.
client_id - это идентификатор приложения Application (client) ID, который мы взяли из Overview
УСТАРЕЛО group_id (когда-то он назывался team_id) - напротив любого канала в MS Teams нажимаем три точки и жмем Get link to channel. В этой ссылке будет параметр - groupId. Это он.

Формируем URL:

https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/authorize?client_id={client_id}&response_type=code&response_mode=query&scope=offline_access%20ChannelMessage.Send

Вводим этот URL в браузере, нас перекидывает на страницу аутентификации, а после успешной аутентификации - на URL вида
```
https://localhost/myapp?code=1......&session_state=0021c0b9-68fb-6cd3-c0ce-49a54fd54a9a
```
так вот параметр code в этом URL и есть одноразовый authorization code, пригодный для получения токена.
Важно обратить внимание на параметр scope. Он определяет круг привилегий (через пробел), доступный токену, полученному с помощью этого кода. В scope присутствует offline_access, а это значит что с помощью этого authorization code помимо короткоживущего access token можно запросить долгоиграющий refresh token, который можно рассматривать как многоразовый authorization code

Получение Access Token и Refresh Token

Дальше все просто - получаем токены:

MS_GRAPH_API_TOKENS_JSON=`curl -s --location --request POST "https://login.microsoftonline.com/${MS_TENANT}/oauth2/v2.0/token" \
    --header 'Content-Type: application/x-www-form-urlencoded' \
    --data-urlencode "client_id=${MS_APPLICATION_ID}" \
    --data-urlencode "code=${AUTHORIZATION_CODE}" \
    --data-urlencode "scope=offline_access ChannelMessage.Send" \
    --data-urlencode "http://localhost/myapp" \
    --data-urlencode "grant_type=authorization_code" 2>/dev/null`
MS_GRAPH_API_TOKEN=`echo ${MS_GRAPH_API_TOKENS_JSON} | awk '{gsub(/\,/,"\n")}1' 2>/dev/null | grep access_token | cut -d':' -f2 | tr -cd '[:alnum:]._-'`
MS_GRAPH_API_REFRESH_TOKEN=`echo ${MS_GRAPH_API_TOKENS_JSON} | awk '{gsub(/\,/,"\n")}1' 2>/dev/null | grep refresh_token | cut -d':' -f2 | tr -cd '[:alnum:]._-'`

Тут MS_TENANT - это все тот же team_id или group_id - Это синонимичные значения в терминологии MS Teams.
Refresh Token - валиден 90 дней, но лучше его периодически обновлять, получая тот же JSON о свежими с токенами уже с помощью имеющегося refresh token:

MS_GRAPH_API_TOKENS_JSON=`curl -s --location --request POST "https://login.microsoftonline.com/${MS_TENANT}/oauth2/v2.0/token" \
        --header 'Content-Type: application/x-www-form-urlencoded' \
        --data-urlencode "client_id=${MS_APPLICATION_ID}" \
        --data-urlencode 'scope=offline_access ChannelMessage.Send' \
        --data-urlencode 'grant_type=refresh_token' \
        --data-urlencode "refresh_token=${MS_GRAPH_API_REFRESH_TOKEN}" 2>/dev/null`
MS_GRAPH_API_TOKEN=`echo ${MS_GRAPH_API_TOKENS_JSON} | awk '{gsub(/\,/,"\n")}1' 2>/dev/null | grep access_token | cut -d':' -f2 | tr -cd '[:alnum:]._-'`
MS_GRAPH_API_REFRESH_TOKEN=`echo ${MS_GRAPH_API_TOKENS_JSON} | awk '{gsub(/\,/,"\n")}1' 2>/dev/null | grep refresh_token | cut -d':' -f2 | tr -cd '[:alnum:]._-'`

Отправка сообщения в канал MS Teams через MS Graph API

MESSAGE="{
  \"body\": {
  \"contentType\": \"html\",
  \"content\": \"Hello World!\"
  }
}"
curl -s -X POST "https://graph.microsoft.com/v1.0/teams/${MS_TEAMS_GROUP_ID}/channels/${MS_TEAMS_CHANNEL_ID}/messages" \
    -H "Authorization: Bearer ${MS_GRAPH_API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d "${MESSAGE}"

ms_teams_search_messages_in_a_channel

anonymous@undisclosed.example.com (Anonymous) — Thu, 04 Dec 2025 14:31:14 +0000

Мне нужно получить тексты сообщений из канала MS Teams с помощью API.
Оказалось, что из GraphQL (https://developer.microsoft.com/en-us/graph/graph-explorer) сделать это можно только со специтальными разрешениями от админа (Chat.Read или Chat.ReadWrite, ChannelMessage.Read.All).
Однако, закрытый API, который испольузет приложение - позволяет как минимум получить список сообщений и preview.
В итоге, я сделал так:

идем в web-интерфейс Teams, нажимаем в браузере F11 и выполняем поиск в нужном канале.
В network находим запрос методом POST на адрес https://substrate.office.com/searchservice/api/v2/query
В заголовках этого запроса берем заголовок Authorization и подставляем в этот скрипт:

#!/bin/bash

export MS_GRAPH_API_TOKEN="Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6Im53WG5YbG9PdndrUUEyN0FiVWV3czd4X2pscDRETzFBX1Uyb1FCUEVSWjgiLCJhbGciOiJSUzI1NiIsIng1dCI6InJ0c0ZULWItN0x1WTdEVlllU05LY0lKN1ZuYyIsImtpZCI6InJ0c0ZULWItN0x1WTdEVlllU05LY0lKN1ZuYyJ9.eyJhdWQiOiJodHRwczovL291dGxvb2s..."

function search_ms_teams_messages {
    curl --silent -X POST "https://substrate.office.com/searchservice/api/v2/query" \
    -H "Authorization: ${MS_GRAPH_API_TOKEN}" \
    -H "Content-Type: application/json" \
    -d '{
  "entityRequests": [
    {
      "entityType": "Message",
      "contentSources": [
        "Teams"
      ],
      "fields": [],
      "propertySet": "Optimized",
      "query": {
        "queryString": "Mikhail Usik AND sent >= 2025-12-01T00:00:00.000Z AND sent < 2025-12-31T00:00:00.000Z AND clientthreadid:19:b89271071f5a4a52b675758165469040@thread.skype AND NOT (isClientSoftDeleted:TRUE)",
        "displayQueryString": "Mikhail Usik"
      },
      "from": 0,
      "size": 100,
      "topResultsCount": 10,
      "filter": {
        "Term": {
          "GroupId": "c0f53b2a-78cd-4722-a378-f2c439c612cb"
        }
      }
    }
  ],
  "QueryAlterationOptions": {
    "EnableAlteration": true,
    "EnableSuggestion": true,
    "SupportedRecourseDisplayTypes": [
      "Suggestion"
    ]
  },
  "cvid": "237bca94-000f-4634-90d4-78207e267d79",
  "logicalId": "c7e32b39-af2f-4dae-a670-80d4df18fd80",
  "scenario": {
    "Dimensions": [
      {
        "DimensionName": "QueryType",
        "DimensionValue": "Messages"
      },
      {
        "DimensionName": "FormFactor",
        "DimensionValue": "general.web.reactSearch"
      }
    ],
    "Name": "powerbar"
  },
  "Context": {
    "EntityContext": [
      {
        "@odata.type": "Microsoft.OutlookServices.Message",
        "Id": "c0f53b2a-78cd-4722-a378-f2c439c612cb",
        "ClientThreadId": "19:b89271071f5a4a52b675758165469040@thread.skype"
      }
    ]
  }
}' 2>/dev/null | jq '.EntitySets[].ResultSets[].Results[].Source.Preview' | tac >> previews.txt
}

search_ms_teams_messages

Полный текст сообщений

Полный текст сообщений можно получить с помощью InternetMessageId и запросов в GraphQL вида:

curl -X GET \
  -H "Authorization: ${MS_GRAPH_API_TOKEN}" \
  -H "Accept: application/json" \
  "https://graph.microsoft.com/v1.0/teams/${MS_TEAMS_TEAM_ID}/channels/${MS_TEAMS_CHANNEL_ID}/messages/${MESSAGE_ID}"

nexus

anonymous@undisclosed.example.com (Anonymous) — Mon, 15 Mar 2021 09:46:36 +0000

PyPI

https://help.sonatype.com/repomanager3/formats/pypi-repositories
У меня задача - создать локальный репозитрий, куда загрузить необходимые проектам зависимости.
Итак. Я создал в nexus репозитрий pypi hosted и назвал его pypi-local.
В итоге - он доступен по адресу: http://repos.rdleas.ru/repository/pypi-local/

Использование созданного репозитория

Для того, чтобы использовать созданный репозиторий нужно прописать его в файле pip.conf. В засисимости от обстоятельств, расположение этого файла может быть различным: https://pip.pypa.io/en/stable/user_guide/#config-file

[global]
index = http://repos.rdleas.ru/repository/pypi-local/pypi
index-url = http://repos.rdleas.ru/repository/pypi-local/simple
#cert = nexus.pem

Если репозитрий защищен паролем, то учестные данные можно прописать в файле .pypirc

[distutils]
index-servers = pypi
[pypi]
repository: http://repos.rdleas.ru/repository/pypi-local/
username: admin
password: admin123

Если репозиторий http (не https), то нужно прописать его в trusted hosts:

[global]
trusted-host = repos.rdleas.ru
index = http://repos.rdleas.ru/repository/pypi-local/pypi
index-url = http://repos.rdleas.ru/repository/pypi-local/simple

Как загружать пакеты в репозиторий pypi

https://packaging.python.org/tutorials/packaging-projects/#uploading-the-distribution-archives
Для того чтобы запушить пакет в созданный репозиторий воспользуемся twine.
Установим его:

sudo pip3 install twine

Теперь можно аплоадить. Ключ -r (или –repository) указывает на репозитрий, прописанный в .pypirc:

twine upload -r pypi <filename>

Скрипт

#!/bin/bash
set +e
packages="./packages"
proxy_user="user"
proxy_pass="pass"
sudo bash -c "pip3 install --proxy http://$proxy_user:$proxy_pass@10.77.70.6:3128 twine"

while read -r package
do
  echo "+++++++++++++++++++++++ $package +++++++++++++++++++++++++"
  bash -c "pip3 download --proxy http://$proxy_user:$proxy_pass@10.77.70.6:3128 $package"
done < "$packages"

for f in ./*.whl ./*.tar.gz
do
 echo "Uploading $f"
 twine upload -r pypi $f
done

nginx-ingress-backends-debug

anonymous@undisclosed.example.com (Anonymous) — Thu, 21 Apr 2022 12:25:17 +0000

Проблема

Нужно посмотреть - какие бекенды попадают в конфиг Nginx Ingress Controller.
Если мы просто выведем текущий конфиг контроллера с помощью

nginx -T

То увидим, что список бекендов апстрима генерируется динамически - https://kubernetes.github.io/ingress-nginx/how-it-works/
Однако, есть способ посмотреть что же там генерируется - это плагин ingress-nginx для kubectl.
Для этого:

Устанавливаем krew, если он еще не установлен. Для этого в bash запускаем такое:

(
  set -x; cd "$(mktemp -d)" &&
  OS="$(uname | tr '[:upper:]' '[:lower:]')" &&
  ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&
  KREW="krew-${OS}_${ARCH}" &&
  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&
  tar zxvf "${KREW}.tar.gz" &&
  ./"${KREW}" install krew
)

Затем в ~/.bashrc дописываем

export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

выполняем

source ~/.bashrc

и проверяем, что плагин krew установился

kubectl krew

Устанавливаем плагин ingress-nginx
```
kubectl krew install ingress-nginx
```
И теперь - смотрим что там с бекендами:
```
kubectl ingress-nginx backends
```
Если вылезает сообщение типа
```
no pods for deployment ingress-nginx-controller found in namespace 
```
- это значит, что плагин пытается найти деплоймент, которым развернут ingress-контроллер, но не может найти этот деплоймент, потому что он называется как-то иначе. Тогда делаем так:
```
kubectl ingress-nginx backends -n ingress --deployment nginx-ingress-nginx-controller
```
то есть указываем неймспейс где развернут ингресс-контроллер и актуальное имя деплоймента.

npm_codeartifacts_auth_proxy

anonymous@undisclosed.example.com (Anonymous) — Tue, 25 Jul 2023 07:41:02 +0000

ЧТо это??

AWS Codeartifacts не позволяют использовать свои репозитриии без аутентификации, что может быть неудобно.
Эти скрипты позволяют настроить прокси, который будет автоматически получать, обновлять и подставлять в заголовки запросов свежие токены.
Таким образом - клиенты могут использовать AWS CodeArtifacts NPM repo без аутентификации (вернее - с пустым токеном).

Openresty LUA based Setup

server {
    listen       $PORT;
    location / {
        access_by_lua_block {
            --ngx.log(ngx.ERR, '################ HEADERS BEFORE AUTH #####################');
            --local h = ngx.req.get_headers();
            --for k, v in pairs(h) do
            --  ngx.log(ngx.ERR, k..' - '..v);
            --end
            --ngx.log(ngx.ERR, '### REQUEST BODY ###');
            --ngx.log(ngx.ERR, ngx.req.get_body_data());
            --ngx.log(ngx.ERR, '###################### AUTH #######################');
            command = [[aws codeartifact get-authorization-token --domain ${CODEARTIFACTS_DOMAIN} --domain-owner ${CODEARTIFACTS_OWNER} --query authorizationToken --output text]];
            local handle = io.popen(command);
            local token = handle:read("*a"):gsub("\n$", "");
            handle:close();
            --ngx.log(ngx.ERR, 'Token - '..token);
            ngx.req.set_header('authorization', 'Bearer '..token);
            ngx.req.set_header('host', '${BACKEND_HOST}');
            --ngx.log(ngx.ERR, '################ HEADERS BEFORE PROXYPASS #####################');
            --local h = ngx.req.get_headers()
            --for k, v in pairs(h) do
            --    ngx.log(ngx.ERR, k..' - '..v);
            --end
        }
        proxy_redirect off;
        proxy_pass ${BACKEND_URL}:${BACKEND_PORT};
    }
}

version: '3.9'

services:
  npm-proxy:
    restart: always
    image: openresty/openresty:1.21.4.1-alpine-fat
    container_name: proxy
    volumes:
    - ./proxy-conf.template:/etc/nginx/conf.d/proxy-conf.template:ro
    ports:
    - "8088:8088"
    environment:
    - CODEARTIFACTS_DOMAIN=artifats-domain
    - BACKEND_URL=https://artifacts-domain-1234567.d.codeartifact.eu-west-1.amazonaws.com
    - BACKEND_PORT=443
    - BACKEND_HOST=artifacts-domain-1234567.d.codeartifact.eu-west-1.amazonaws.com
    - PORT=8088
    command: >
      /bin/bash -c "
      apk add --no-cache aws-cli &&
      export CODEARTIFACTS_OWNER=`aws sts get-caller-identity | grep Account | cut -d':' -f2 | tr -d '\" ,'` &&
      envsubst < /etc/nginx/conf.d/proxy-conf.template > /etc/nginx/conf.d/default.conf &&
      cat /etc/nginx/conf.d/default.conf &&
      openresty -g 'daemon off;'"
  node:
    restart: always
    image: node:18
    container_name: node
    command: >
      /bin/bash -c "sleep infinity"

проверка

git clone https://github.com/wix-incubator/empty-package
cd empty-package/
sed -i 's/https\:\/\/registry\.npmjs\.org\//http\:\/\/proxy\:8088\/npm\/anima-npm\//' ./package.json
npm config set registry=http://proxy:8088/npm/anima-npm/
npm config set //proxy:8088/npm/anima-npm/:_authToken=e30=
#### npm config set //proxy:8088/npm/anima-npm/:_authToken=`echo -n '{}' | base64`

Plain Nginx setup

docker-compose.yml

version: '3.9'

services:
  npm-proxy:
    restart: always
    image: ubuntu/nginx:1.18-22.04_edge
    container_name: proxy
    volumes:
    - ./npm-proxy-entrypoint.sh:/start.sh:ro
    - ./npm-proxy-conf.template:/etc/nginx/conf.d/npm-proxy-conf.template:ro
    ports:
    - "8088:8088"
    environment:
    - SERVER_NAME=npm-proxy.domain.com
    - CODEARTIFACTS_DOMAIN=artifacts-domain
    - BACKEND_URL=https://artifacts-domain-1234567.d.codeartifact.eu-west-1.amazonaws.com
    - BACKEND_PORT=443
    - BACKEND_HOST=artifacts-domain-1234567.d.codeartifact.eu-west-1.amazonaws.com
    - PORT=8088
    - REGION=eu-west-1
    command: >
      /bin/bash /start.sh

npm-proxy-entrypoint.sh

#!/bin/bash
set -e
echo "Installing AWS CLI..."
apt-get update 2>&1>/dev/null
apt-get install -y awscli 2>&1>/dev/null
echo "AWS CLI Installed!!!"
export CODEARTIFACTS_OWNER=`aws sts get-caller-identity | grep Account | cut -d':' -f2 | tr -d '\" ,'`
ln -sf /dev/stdout /var/log/nginx/access.log && ln -sf /dev/stderr /var/log/nginx/error.log
nginx -g 'daemon off;' &
while true; do
    export AUTH_TOKEN=`aws codeartifact get-authorization-token --region ${REGION} --domain ${CODEARTIFACTS_DOMAIN} --domain-owner ${CODEARTIFACTS_OWNER} --query authorizationToken --output text | tr -d '\n'` 
    envsubst < /etc/nginx/conf.d/npm-proxy-conf.template > /etc/nginx/conf.d/default.conf
    nginx -s reload
    sleep 800
done

npm-proxy-conf.template

server {
    listen       $PORT;
    server_name  $SERVER_NAME;
    gzip_static off;
    default_type application/octet-stream;
    location = /health {
        access_log off;
        add_header 'Content-Type' 'application/json';
        return 200 '{"status":"UP"}';
    }
    location / {
        proxy_method GET;
        sub_filter '$BACKEND_HOST' '$SERVER_NAME';
        sub_filter_types application/json;
        sub_filter_once off;

        proxy_http_version 1.1;
        proxy_set_header Host $BACKEND_HOST;
        proxy_set_header Authorization 'Bearer $AUTH_TOKEN';
        proxy_pass_request_headers off;

        proxy_pass $BACKEND_URL:$BACKEND_PORT;
    }
}

NPM Nginx-based caching proxy

https://gist.github.com/dctrwatson/5785675

user www-data;
worker_processes 4;

error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

events {
  worker_connections 1024;
}

http {
  include /etc/nginx/mime.types;

  access_log off;

  default_type application/octet-stream;

  sendfile on;
  tcp_nodelay on;
  tcp_nopush off;

  reset_timedout_connection on;

  server_tokens off;

  # Cache 10G worth of packages for up to 1 month
  proxy_cache_path /var/lib/nginx/npm levels=1:2 keys_zone=npm:16m inactive=1M max_size=10G;

  # Multiple server definitions makes nginx retry
  upstream registry_npm {
    server registry.npmjs.org;
    server registry.npmjs.org;
    keepalive 16;
  }

  gzip on;
  gzip_types application/json text/css text/javascript;
  gzip_proxied any;
  gzip_vary on;

  server {
    listen 80 default_server;
    server_name npm.example.com;

    root /var/www;

    proxy_cache npm;
    proxy_cache_key $uri;
    proxy_cache_lock on;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;

    proxy_http_version 1.1;
    proxy_pass_request_headers off;
    proxy_set_header Host registry.npmjs.org;

    location / {
      proxy_cache_valid any 5m;

      add_header X-Cache $upstream_cache_status;

      proxy_pass http://registry_npm;
    }

    location ~ ^/.+/-/.+ {
      proxy_cache_valid any 1M;

      add_header X-Cache $upstream_cache_status;

      proxy_pass http://registry_npm;
    }
  }
}

openebs

anonymous@undisclosed.example.com (Anonymous) — Tue, 30 Mar 2021 08:39:11 +0000

OpenEBS

Тут я буду собирать какие-то заметки по поводу работы с OpenEBS.

Расширение томов LocalPV

https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/
Допустим, для какого-то приложения у меня создан StorageClass LocalPV, который привязан к выделенной ноде и на ней приложение хранит данные:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nexus-storage
  annotations:
    openebs.io/cas-type: local
    cas.openebs.io/config: |
      - name: StorageType
        value: hostpath
      - name: BasePath
        value: /storage/nexus
      - name: NodeAffinityLabel
        value: "openebs.io/nexus"
provisioner: openebs.io/local
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Том был создан при разворачивании приложения helm-чартом, в котором указано использование данного StorageClass.
Приложение работало и сожрало все место. Как расширить том?
Делаем так:

увеличиваем место под данным томом (в директории /storage/nexus) на уровне хоста (lvresize, resize2fs…)
Прямо на ходу разрешаем StorageClass'у делать расширяемые тома (allowVolumeExpansion: true)
редактируем том и увеличиваем его - spec.capacity.storage
Редактируем и увеличиваем spec.resources.requests.storage

otus_course_final

anonymous@undisclosed.example.com (Anonymous) — Mon, 15 Nov 2021 16:04:08 +0000

Сертификат OTUS

https://otus.ru/certificate/a3bb5b94f88e4582a53f606a1f1ab0ae/

Проектная работа по курсу otus kubernetes

Разворачивание кластера в GCP:

Deploy Kubernetes Load Balancer Service with Terraform on GCP
Modular Load Balancing with Terraform
Как вручную запустить кластер (можно делать из ansible) в GCP - https://docs.projectcalico.org/getting-started/kubernetes/self-managed-public-cloud/gce
Как создавать машинки из terraform: https://www.nebulaworks.com/blog/2019/04/22/simplify-your-gce-instance-bootstrapping-with-terraform/ https://linux-notes.org/rabota-s-google-cloud-platform-compute-instance-i-terraform-v-unix-linux/

Как запустить managed кластер GKE - https://www.padok.fr/en/blog/kubernetes-google-cloud-terraform-cluster
Какое-то самописное решение - https://medium.com/searce/kubernetes-deployment-on-google-compute-engine-using-terraform-8d6075cf4d3f
Специальный модуль для terraform: https://github.com/terraform-google-modules/terraform-google-k8s-gce
Самописное решение Terraform + Ansible https://medium.zenika.com/a-custom-kubernetes-cluster-on-gcp-in-7-minutes-with-terraform-and-ansible-75875f89309e

Подготовка

wget https://releases.hashicorp.com/terraform/0.13.1/terraform_0.13.1_linux_amd64.zip
unzip ./terraform_0.13.1_linux_amd64.zip 
sudo mv ./terraform /usr/local/bin/terraform

echo "deb https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
sudo apt-get update && sudo apt-get -y upgrade && sudo apt-get -y install google-cloud-sdk kubectl

gcloud init

gcloud выдаст ссылку, которую надо будет открыть в браузере, согласиться выдать разрешения и скопировать verification code.
Выбираем зону 1 (us-east1-b) и тип машин будем юзать e2-standard-2 (2vCPU, 8GB RAM).
Включаем необходимые APIшки:

gcloud services enable compute.googleapis.com
gcloud services enable servicenetworking.googleapis.com
#gcloud services enable cloudresourcemanager.googleapis.com
#gcloud services enable container.googleapis.com

Теперь можно получить токен, с которым будем ходить в GCP.

gcloud auth print-access-token

И в дальнейшем полученную строку будем юзать в качестве значения параметра access_token в конфиге terraform-провайдера google.

Текущий статус

Поднимаются виртуалки с помощью terraform по списку.
Между виртуалками есть сеть и у каждой есть внешний IP.
Формируется inventory-файл для kubespray и нормально разворачивается кластер.
Цепляются пара дисков (один монтируется в /var/lib/docker, а второй - /var/lib/data - для PersistentVolumes)
Протестировал провижининг OpenEBS Local PV Hostpath. Вроде работает OpenEBS - хороший вариант В итоге - включил провижининг, который идет в комплекте с kubespray - rancher/local-path-provisioner (local_path_provisioner_enabled: true)
Развернул ELK (с помощью оператора и чартика).

Задачи

Настроить DNS-зону https://cloud.google.com/dns/docs/zones Зону ucent.ru завел в GCP.
Настроить ingress. По дефолту ставится istio, который и может быть ingress'ом. https://habr.com/ru/company/southbridge/blog/441616/ https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-control/
Настроить CertManager
Настроить выгрузку в docker registry собранных образов. Выгрузка работает (в docker registry в кластере). Нужно приделать сертификат для registry. https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/
Создать pipeline trigger, для того, чтобы можно было запустить пайплайн из terraform.
Разобраться с ингрессом.

По сетевой части нашлось вот что: https://github.com/Wi3ard/k8s-nginx-ingress/blob/gke-gdns-certmgr-wildcard/main.tf

Нужно сделать между ними балансировщик. https://linux-notes.org/rabota-s-google-cloud-platform-compute-forwarding-rule-i-terraform-v-unix-linux/

https://www.terraform.io/docs/providers/google/r/compute_global_forwarding_rule.html#

Нужно прописывать DNS-записи для всех сервисов
Развернуть Ingress (NodePort)
Развернуть CertManager
Нужно забрать оттуда admin.conf от кластера кубера. Сделал, но наверное не надо. api-сервер слушает на локальном адресе.

ЛИШНЕЕ и пока не очен понятное

Создадим Service Account:

gcloud iam service-accounts create otus-course-project --display-name "Otus Course Project Service Account"

И посмотрим какие с ней связаны ключи:

gcloud iam service-accounts keys list --iam-account=otus-course-project@otus-kuber-course.iam.gserviceaccount.com

Сгенерируем новый (https://cloud.google.com/sdk/gcloud/reference/iam/service-accounts/keys/create):

gcloud iam service-accounts keys create ./otus-kubernetes-course.yaml --iam-account=otus-course-project@otus-kuber-course.iam.gserviceaccount.com

В результате - получим файлик otus-kubernetes-course.yaml, который уже может быть использован terraform.
И потом активируем его:

gcloud auth activate-service-account otus-course-project@otus-kuber-course.iam.gserviceaccount.com --key-file=./otus-kubernetes-course.yaml

Также можно привязать уже имеющийся файлик примерно вот так: https://cloud.google.com/sdk/gcloud/reference/auth/activate-service-account .
В дальнейшем переключаться между аккаунтами можно так:

gcloud config set account otus-course-project@otus-kuber-course.iam.gserviceaccount.com

php-fmp-nginx-performance-diags

anonymous@undisclosed.example.com (Anonymous) — Fri, 21 Jul 2023 10:46:26 +0000

https://gist.github.com/holmberd/44fa5c2555139a1a46e01434d3aaa512?permalink_comment_id=3143513

Диагностика и настройка параметров php-fpm в связке с nginx

Текущие значения можно увидеть так:

php-fpm -tt

Определяем - не упирамся ли мы в лимит max_children ??

  sudo grep max_children /var/log/php?.?-fpm.log.1 /var/log/php?.?-fpm.log

Определяем - не упирамся ли мы в память:

  free -h

Для всех процессов php:

ps -ylC php-fpm7.0 --sort:rss

Средняя загрузка:

ps --no-headers -o "rss,cmd" -C php-fpm7.0 | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }'

Суммарная загрузка памяти процессами php:

ps -eo size,pid,user,command --sort -size | awk '{ hr=$1/1024 ; printf("%13.2f Mb ",hr) } { for ( x=4 ; x<=NF ; x++ ) { printf("%s ",$x) } print "" }' | grep php-fpm

Вычисляем оптимальный размер max_children Based on RAM

  pm.max_children = Total RAM dedicated to the web server / Max child process size

  System RAM: 2GB

  Average Pool size: 85Mb

  pm.max_children = 1500MB / 85MB = 17

Based on average script execution time

  max_children = (average PHP script execution time) * (PHP requests per second)
  visitors = max_children * (seconds between page views) / (avg. execution time)

Configure

sudo vim /etc/php/7.0/fpm/pool.d/www.conf

pm.max_children = 17
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_request = 1000

; Choose how the process manager will control the number of child processes.
; Possible Values:
;   static  - a fixed number (pm.max_children) of child processes;
;   dynamic - the number of child processes are set dynamically based on the
;             following directives:
;             pm.max_children      - the maximum number of children that can
;                                    be alive at the same time.
;
;             pm.start_servers     - the number of children created on startup.
;                                    this value must not be less than min_spare_servers 
;                                    and not greater than max_spare_servers.
;
;             pm.min_spare_servers - the minimum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is less than this
;                                    number then some children will be created.
;
;             pm.max_spare_servers - the maximum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is greater than this
;                                    number then some children will be killed.
; Note: This value is mandatory.

postgres_investigating_slowness

anonymous@undisclosed.example.com (Anonymous) — Mon, 26 May 2025 10:46:08 +0000

https://www.cockroachlabs.com/blog/high-cpu-usage-postgres/

Top five queries by total execution time

To enable pg_stat_statements, add pg_stat_statements to shared_preload_libraries in the DB parameter group

SELECT
	query,
	calls,
	total_exec_time,
	rows
FROM
	pg_stat_statements
ORDER BY
	total_exec_time DESC
LIMIT
	5;

в RDS Aurora нужно включить предварительно pg_stat_statements, добавив в группе параметров pg_stat_statements в список shared_preload_libraries

SELECT
	query,
	calls,
	total_exec_time,
	rows
FROM
	aurora_stat_statements()
ORDER BY
	total_exec_time DESC
LIMIT
	5;

Current active connections

SELECT * FROM pg_stat_activity WHERE state = ‘active’;
SHOW max_connections;

SELECT
  pid,
  now() - pg_stat_activity.query_start AS duration,
  query,
  state
FROM pg_stat_activity
WHERE (now() - pg_stat_activity.query_start) > interval '5 minutes';

Список таблиц, к которым много обращений

https://aws.amazon.com/blogs/database/determining-the-optimal-value-for-shared_buffers-using-the-pg_buffercache-extension-in-postgresql/
Оценить загруженность таблиц можно по тому, сколько памяти для них используется в shared buffers.

CREATE EXTENSION pg_buffercache;
SELECT c.relname,
pg_size_pretty(count(*)*8192) AS buffer_size,
pg_size_pretty(pg_relation_size(c.oid)) as relation_size,
Round(100.0 * Count(*) / (SELECT setting
FROM pg_settings
WHERE name = 'shared_buffers') :: INTEGER, 2) AS buffers_percent,
ROUND(count(*)*8192*100/ pg_relation_size(c.oid)::numeric, 2 ) AS relation_percent,
CASE
WHEN c.relkind = 'r' THEN 'table'
WHEN c.relkind = 'i' THEN 'index'
WHEN c.relkind = 'S' THEN 'sequence'
WHEN c.relkind = 't' THEN 'TOAST table'
WHEN c.relkind = 'v' THEN 'view'
WHEN c.relkind = 'm' THEN 'materialized view'
WHEN c.relkind = 'c' THEN 'composite type'
WHEN c.relkind = 'f' THEN 'foreign table'
WHEN c.relkind = 'p' THEN 'partitioned table'
WHEN c.relkind = 'I' THEN 'partitioned index'
ELSE 'Unexpected relkind'
END as relation_type
FROM pg_class c
INNER JOIN pg_buffercache b
ON b.relfilenode = c.relfilenode
INNER JOIN pg_database d
ON ( b.reldatabase = d.oid
AND d.datname = Current_database() )
GROUP BY c.relname, c.oid
ORDER BY pg_total_relation_size(c.oid) DESC
LIMIT 10;

prometheus_federation

anonymous@undisclosed.example.com (Anonymous) — Fri, 11 Mar 2022 09:45:42 +0000

Задача

Нужно настроить:

Выделенный сервер логирования Prometheus + Grafanana
Настроить сбор метрик из подов, работающих в двух кластерах k8s.
Настроить дашборды в Grafana.
Сделать это всё все в соответствии с IaC, чтобы можно было быстро реплицировать и масштабировать.

Настройки в кластере k8s с опубликованными приложениями

Я предполагаю, что работы идут в уже настроенном кластере, в котором есть Ingress Controller и из которого можно публиковать сервисы (prometheus) наружу.
В кластере в котором работают приложения нужно:

Развернуть оператор Prometheus, который будет управлять объектами Prometheus и ServiceMonitor
Создать необходимые для работы объекты (сервис-аккаунт, роль, rolebinding)
Опубликовать Prometheus через Ingress (в том числе настроить basic-аутентифкацию для доступа к метрикам)
Создать ServiceMonitor'ы для сбора метрик

Установка оператора prometheus

https://grafana.com/docs/grafana-cloud/kubernetes/prometheus/prometheus_operator/
Создаем CRD's и устанавливаем оператора:

NS=monitoring
kubectl create ns $NS
wget https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/master/bundle.yaml
sed -i "s/  namespace: default/  namespace: $NS/g" ./bundle.yaml
kubectl create -f ./bundle.yaml

Создаем сервис-аккаунт, роль и даем права:

kubectl apply -n $NS -f -<<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources:
  - nodes
  - nodes/metrics
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources:
  - configmaps
  verbs: ["get"]
- apiGroups:
  - networking.k8s.io
  resources:
  - ingresses
  verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: $NS
EOF

Создаем Prometheus:
https://github.com/prometheus-operator/prometheus-operator/issues/2382

kubectl apply -n monitoring -f - <<EOF
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
  labels:
    app: prometheus
spec:
  externalUrl: https://ingress.domain.com/prometheus/
  routePrefix: /prometheus
  image: quay.io/prometheus/prometheus:v2.22.1
  nodeSelector:
    kubernetes.io/os: linux
  replicas: 2
  resources:
    requests:
      memory: 400Mi
  securityContext:
    fsGroup: 2000
    runAsNonRoot: true
    runAsUser: 1000
  serviceAccountName: prometheus
  version: v2.22.1
  ruleNamespaceSelector:
    matchLabels:
      monitoring: prometheus
  serviceMonitorNamespaceSelector:
    matchLabels:
      monitoring: prometheus
  serviceMonitorSelector: {}
---
apiVersion: v1
kind: Service
metadata:
  name: prometheus-web
  labels:
    prometheus: prometheus
spec:
  ports:
  - name: web
    port: 9090
    targetPort: web
  selector:
    prometheus: prometheus
  sessionAffinity: ClientIP
  type: ClusterIP
EOF

Тут важно обратить внимание на параметры externalUrl и routePrefix. Они должны соответветствовать тому, что будет прописано в Ingress. Они же параметры командной строки prometheus - –web.external-url и –web.route-prefix соответственно.

Пометим неймспйесы, которые должны мониториться этим прометиусом

kubectl label ns monitoring monitoring=prometheus

Публикация prometheus через Ingress

Prometheus будет опубликован наружу через Ingress и защищен basic-аутентификацией.

Создадим секрет для basic-аутентификации:

kubectl create -n monitoring secret generic prometheus-basic-auth --from-literal=auth=username:$(openssl passwd -5 superpassword)

И теперь можем создать ингресс:
https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/user-guides/exposing-prometheus-and-alertmanager.md#ingress

kubectl apply -n monitoring -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: prometheus-metrics
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: prometheus-basic-auth
    nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required'
spec:
  rules:
  - host: ingress.domain.com
    http:
      paths:
      - backend:
          service:
            name: prometheus-web
            port:
              number: 9090
        path: /prometheus
        pathType: Prefix
  tls:
  - hosts:
    - ingress.domain.com
    secretName: ingress-domain-com-tls
EOF

Тут важно - path должен быть таким же как и в настройках prometheus, имя секрета в аннотации - соответствовать имени созданного серкрета с учеткой basic-auth. Можно проверить:

curl -u 'username:superpassword' https://ingress.domain.com/prometheus/metrics

Или какие-то более осмысленные метрики:

curl -u 'username:superpassword' -g 'https://ai-eu-1.voximplant.com/prometheus/federate?match[]={container="gateway-container"}'

Настройка ServiceMonitors

https://docs.openshift.com/container-platform/4.9/rest_api/monitoring_apis/servicemonitor-monitoring-coreos-com-v1.html

kubectl apply -n monitoring -f -<<EOF
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: gateway
spec:
  selector:
    matchLabels:
      app: gateway
  namespaceSelector:
    matchNames:
    - nlu-prod
  endpoints:
  - targetPort: 8080
    path: /metrics
    scheme: http
    interval: 10s
EOF

Траблшутинг проблем с сервис-мониторами: https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/troubleshooting.md#troubleshooting-servicemonitor-changes Что тут важно:

У сервисов должны быть прописаны метки, которые затем прописываются в селектор сервисмониторов.
Эндпоинт с метриками задаем с помощью либо по имени порта (параметр port), либо - по номеру порта (параметр targetPort) в конфиге сервиса.

Настройки на основном сервере логирования

На основоном сервере логирования но настроить federation
Примерно так: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config

# https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config
- job_name: 'kubernetes-pods-aws'
  scrape_interval: 15s

  honor_labels: true
  metrics_path: '/prometheus/federate'

  basic_auth:
    username: username
    password: superpassword

  scheme: https

  params:
    match[]:
      - '{job=~".+"}'

  static_configs:
    - targets:
      - 'remote.prometheus.domain.com:443'
      labels:
        cluster: remote_prometheus_domain_com

И на основном сервере логирования можно выполнить запрос какого-либо значения, указав в качестве параметра фильтрации - метку для данного таргета:

curl -g 'http://127.0.0.1:9090/api/v1/query?query=system_cpu_usage{container="container_name",cluster="remote_prometheus_domain_com"}'

proxy_pass_auth

anonymous@undisclosed.example.com (Anonymous) — Thu, 11 Feb 2021 16:31:12 +0000

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

proxy_pass с аутентификацией по сертификату

    server {
        listen      8011;

        location / {
            proxy_pass                    https://api.domain.local:8443;
            proxy_ssl_certificate         /etc/nginx/ssl/api.domain.local/client.pem;
            proxy_ssl_certificate_key     /etc/nginx/ssl/api.domain.local/key_nopasswd.pem;
            proxy_ssl_protocols           TLSv1 TLSv1.1 TLSv1.2;
            proxy_ssl_ciphers             HIGH:!aNULL:!MD5;
            proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;

            proxy_ssl_verify        on;
            proxy_ssl_verify_depth  2;
            proxy_ssl_session_reuse on;
        }
    }

proxy_pass с kerberos-аутентификацией на upstream

https://blog.inf.ed.ac.uk/squinney/2018/03/29/easy-gssapi-authentication/
https://stackoverflow.com/a/38664954
https://www.ibm.com/support/knowledgecenter/en/SSPT3X_3.0.0/com.ibm.swg.im.infosphere.biginsights.admin.doc/doc/kerberos_webconsole.html
http://www.unstructureddatatips.com/hadoop-rest-api-webhdfs-on-onefs/

С реализацией аутентификации kerberos всё несколько сложнее. Я не нашел готовой реализации этого функционала, поэтому - сделал из подручных средств.
Нужно:

иметь nginx с поддержкой lua - openresty
установить билиотеки kerberos и настроить krb5.conf
curl, nslookup

В моей реализации при попытке ображения к заданному location будет запускаться curl с заданными параметрами (логином, паролем и URL) и возвращать ответ.
То есть весь функционал по реализации аутентификации переездает в curl.
Список переменных среды будет такой:

DOMAIN=domain.local
DOMAIN_USER="username"
DOMAIN_USER_PASS="userpassword"
KRB5_CLIENT_KTNAME=/keytab
KRB5CCNAME=/krb5cc
CURL_CA_BUNDLE=/etc/ssl/certs/ca.pem
CURL_OPTS='--http1.1 -H "Content-Type: application/xml; charset=utf-8" -X POST -v --negotiate -u :'
URL='https://krb-protected-server.domain.local:1111/location/method'
PORT=8088

А стартовый скрипт контейнера такой:

#!/bin/bash
DOMAIN_CONTROLLERS=`nslookup -query=any _ldap._tcp.dc._msdcs.$DOMAIN | grep "_ldap._tcp.dc._msdcs.$DOMAIN" | grep 389 | awk '{print $7}'`
DEFAULT_REALM="${DOMAIN^^}"
#########################################
### Setup Kerberos /etc/krb5.conf
#########################################
LIBDEFAULTS=$(cat <<EOF
[libdefaults]
dns_lookup_kdc = true
dns_lookup_realm = false
default_realm = $DEFAULT_REALM
clockskew = 300
#default_ccache_name = FILE:/tmp/krb5cc_%{uid}
EOF
)

REALMS_KDC=$(for i in $DOMAIN_CONTROLLERS; do echo "kdc = $i";done)

REALMS=$(cat <<EOF

[realms]
$DEFAULT_REALM = {
$REALMS_KDC
default_domain = $DEFAULT_REALM
}
EOF
)

DOMAIN_REALM=$(cat <<EOF

[domain_realm]
.$DOMAIN = $DEFAULT_REALM
$DOMAIN = $DEFAULT_REALM

[appdefaults]
pam = {
        ticket_lifetime = 1d
        renew_lifetime = 1d
        forwardable = true
        proxiable = false
        minimum_uid = 1
}
EOF
)

echo "$LIBDEFAULTS" > /etc/krb5.conf
echo "$REALMS" >> /etc/krb5.conf
echo "$DOMAIN_REALM" >> /etc/krb5.conf

#####################################
### Create keytab and kcc
#####################################
{
printf "%b" "addent -password -p $DOMAIN_USER -k 1 -e aes256-cts-hmac-sha1-96\n" 
sleep 3
printf "%b" "$DOMAIN_USER_PASS\nwrite_kt /$KRB5_CLIENT_KTNAME"
} | ktutil 
kinit -k -t $KRB5_CLIENT_KTNAME $DOMAIN_USER


########################################
### Создаем файл конфига для openresty
########################################
cat <<EOF > /etc/nginx/conf.d/default.conf:

server {
    listen       $PORT;


    location / {
      content_by_lua_block {
        ngx.req.read_body()
        local request_body = ngx.req.get_body_data()
        command = "curl $CURL_OPTS -d '"..request_body.."' $URL";
        local handle = io.popen(command);
        local result = handle:read("*a");
        handle:close();
        ngx.print(result);
      } 
    }
}
EOF

Dockerfile

FROM openresty/openresty:buster
RUN set -ex \
  && apt-get update \
  && apt-get upgrade -y \
  && apt-get install -y \
  curl \
  krb5-user \
  gss-ntlmssp \
  libsasl2-modules-gssapi-mit \
  ca-certificates

rebrain_devops_course

anonymous@undisclosed.example.com (Anonymous) — Sun, 12 Jan 2020 16:51:29 +0000

Что это

На этой страничке я фиксировал свое прохождение курса DevOps от https://rebrainme.com/.
Тут были спойлеры с ответами :)
Однако, вероятный правообладатель Илья вежливо попросил меня удалить её, ссылаясь на условия оферты (которые я и не читал)…
Учитесь теперь сами :)

setup_jenkins_on_kubernetes

anonymous@undisclosed.example.com (Anonymous) — Thu, 23 Apr 2020 10:51:58 +0000

Установка Jenkins с помощью helm

kubectl create ns jenkins
helm install --name jenkins --namespace jenkins stable/jenkins -f ./values-autosys.yaml

В результате в неймспейсе jenkins создадутся все нужные объекты, однако pod будет в состоянии pending, потому что у него отсутсвует PersistentVolume, запрашиваемый при помощи PersistentVolumeClaim.

values-autosys.yaml

master:
  Name: jenkins-master
  overwriteConfig: true
  # hostNetworking: true
  ingress:
    enabled: true
    # For Kubernetes v1.14+, use 'networking.k8s.io/v1beta1'
    apiVersion: "extensions/v1beta1"
    labels: {}
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt
      kubernetes.io/ingress.class: nginx
    hostName: jenkins.autosys.tk
    tls:
    - hosts:
      - jenkins.autosys.tk
      secretName: jenkins-autosys-tk-tls

persistence:
  enabled: true
  storageClass: jenkins

jenkins pod Init:0/1

Сразу после разворачивания pod jenkins у меня находился в состоянии Init:0/1, а в статусе pod'а можно обнаружить такое:

message: 'containers with incomplete status: [copy-default-config]'

В это время в поде jenkins'а работает контейнер copy-default-config, который скачивает с jenkins.io различные компоненты, необходимые для работы (плагины). Ход этого процесса можно наблюдать так:

kubectl logs -n jenkins jenkins-.... -c copy-default-config -f

В контейнере этот процесс выполняется скриптом: /var/jenkins_config/apply_config.sh

Создадим StorageClass и PersistentVolume

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: jenkins
  namespace: jenkins
provisioner: kubernetes.io/no-provisioner
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolume
metadata:
   name: jenkins-pv
   namespace: jenkins
   labels:
     app: jenkins
spec:
  capacity:
    storage: 10Gi
  accessModes:
  - ReadWriteOnce
  storageClassName: jenkins
  hostPath:
    path: "/kubernetes_volumes/jenkins-home"
    type: Directory
  persistentVolumeReclaimPolicy: Retain

Пароль учетки admin

printf $(kubectl get secret --namespace jenkins jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 --decode);echo

Jenkins URL

export SERVICE_IP=$(kubectl get svc --namespace default jenkins --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}")
echo http://$SERVICE_IP:8080/login

Дадим права на создание pod'ов

kubectl create clusterrolebinding jenkins --clusterrole cluster-admin --serviceaccount=jenkins:default

Конфигурация после установки

После установки нужно как минимум сконфигурировать параметры Jenkins Location:

Jenkins URL
System Admin e-mail address

Ссылки

https://habr.com/ru/post/442614/

setup_pgadmin_on_kubernetes

anonymous@undisclosed.example.com (Anonymous) — Wed, 10 Feb 2021 21:16:22 +0000

https://hub.helm.sh/charts/cetic/pgadmin

helm repo add cetic https://cetic.github.io/helm-charts
helm repo update
helm install cetic/pgadmin --name pgadmin --namespace pgadmin --set image.repository=dpage/pgadmin4:4.15 --set service.type=ClusterIP --set image.pullPolicy=IfNotPresent

PersistentVolume

apiVersion: v1
kind: PersistentVolume
metadata:
   name: pgadmin-pv
   namespace: pgadmin
   labels:
     app: pgadmin
spec:
  capacity:
    storage: 4Gi
  accessModes:
  - ReadWriteOnce
  hostPath:
    path: "/kubernetes_volumes/pgadmin-data"
    type: Directory
  persistentVolumeReclaimPolicy: Retain

Ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: letsencrypt
  name: pgadmin-ingress
  namespace: pgadmin
spec:
  rules:
  - host: pgadmin.autosys.tk
    http:
      paths:
      - backend:
          serviceName: pgadmin
          servicePort: 80
        path: /
  tls:
  - hosts:
    - pgadmin.autosys.tk
    secretName:  pgadmin-autosys-tk-tls

Ошибки

После апгрейда docker-образа с версии 4.15 до 4.17 под не смог запуститься с ошибкой:

WARNING: Failed to set ACL on the directory containing the configuration database: [Errno 1] Operation not permitted: '/var/lib/pgadmin'
PermissionError: [Errno 1] Operation not permitted: '/var/lib/pgadmin/sessions'

Это произошло потому, что у пользователь, от имени которого исполняется pgadmin, не является владельцем директории, которая смонтирована как persistentVolume. Поэтому, когда контейнер запускается (но еще не упал с Error) нужно найти процесс pgadmin:

#ps -aux | grep pgadmin
5050     16492  0.0  0.1  24720 22892 ?        Ss   16:07   0:00 /usr/local/bin/python /usr/local/bin/gunicorn --timeout 86400 --bind [::]:80 -w 1 --threads 25 --access-logfile - run_pgadmin:app

И сделать owner'ом папки пользователя с указанным id. В хостовой системе, на которой исполняется контейнер, такого пользователя может и не быть. Главное, чтобы в ACL директории был прописан правильный id:

sudo chown 5050:5050 /kubernetes_volumes/pgadmin-data/ -R

Проблемы

Если нужно, чтобы при входе в PGAdmin сразу подключался сервер, то нужно сделать две вещи - заполнить файл с определениями серверов /pgadmin4/servers.json и заполнить файл pgpass, который хранит пароли для заданных серверов/бд/пользовтелей.
Если с заполнением файла /pgadmin4/servers.json всё более-менее понятно (за исключением того, что путь PassFile задается относительно директории пользователя, что само по себе нетривиально), то вот с файлом pgpass всё не очень просто.
В документации написано, что права на этот файл должны быть строго не шире, чем 0600, то есть права на чтение должен иметь только владелец файла.
Однако, если pgadmin работает в кластере kubernetes, содержимое файла pgpass монтируется из секрета а для пода задан securityContext, то defaultMod для файла смонтированного из секрета не применяется (так написано тут: https://github.com/kubernetes/kubernetes/issues/89153 и тут: https://github.com/kubernetes/kubernetes/issues/57923). В итоге - всё оказывается сложнее, но выход есть!
Итак, я использую чарт pgadmin в качестве сабчарта (наряду с чартом postgresql) и хочу, чтобы в конфиг PGAdmin автоматически попадали параметры развернутого postgresql.
Для этого мне понадобилось

Секрет с содержимым файла pgpass

{{- if .Values.pgadmin4.enabled -}}
apiVersion: v1
kind: Secret
metadata:
  name: pgpassfile
  labels:
data:
  pgpassfile: {{ include "pgadmin4.pgpassfile" . | b64enc | quote }}
{{- end}}

Содержимое файла pgpass формируется хелпером

{{- define "pgadmin4.pgpassfile" -}}
{{ .Values.global.postgresql.fullnameOverride }}:{{ .Values.global.postgresql.service.port }}:*:{{ .Values.global.postgresql.postgresqlUsername }}:{{ .Values.global.postgresql.postgresqlPassword }}
{{ end }}

Хелпер для формирования файла /pgadmin4/servers.json (хелпер родительского чарта переопределяет хелпер сабчарта pgadmin4)

{{/*
Определение сервера для PGAdmin
*/}}
{{- define "pgadmin.serverDefinitions" }}
{
    "Servers": {
        "1": {
            "Name": "PostgeSql-{{ .Values.global.environment }}",
            "Group": "Servers",
            "Host": "{{ .Values.global.postgresql.fullnameOverride }}",
            "Port": "{{ .Values.global.postgresql.service.port }}",
            "MaintenanceDB": "{{ .Values.global.postgresql.postgresqlDatabase }}",
            "Username": "{{ .Values.global.postgresql.postgresqlUsername }}",
            "SSLMode": "prefer",
            "Comment": "Preconfigured PostgreSQL Server",
            "DBRestriction": "{{ .Values.global.postgresql.postgresqlDatabase }}",
            "PassFile": "/pgpass"
        }
    }
}
{{- end -}}

Проблему с правами на файл pgpass решаем с помощью init-контейнера, который монтирует секрет в файл, а затем - копирует этот файл в нужную папку и задает ему нужные права:

  extraSecretMounts:
  - name: pgpassfile
    secret: pgpassfile
    subPath: pgpassfile
    mountPath: "/pgpass"
    readOnly: true
  extraInitContainers: |
    - name: pgpass-permissions-init
      image: "docker.rdleas.ru/dpage/pgadmin4:4.29"
      command:
      - "/bin/ash"
      - "-c"
      - "/bin/mkdir -p /var/lib/pgadmin/storage/pgadmin && /bin/cp /pgpass /var/lib/pgadmin/storage/pgadmin/pgpass && /bin/chmod 0600 /var/lib/pgadmin/storage/pgadmin/pgpass"
      securityContext:
        runAsUser: 0
      volumeMounts:
      - mountPath: /pgpass
        name: pgpassfile
        readOnly: false
        subPath: pgpassfile
      - mountPath: /var/lib/pgadmin
        name: pgadmin-data

В файле values родительского чарта записи такие:

global:
  environment: dev
  postgresql: 
    fullnameOverride: postgresql
    postgresqlUsername: api-user
    postgresqlPassword: tvJk3XrqM3d7xX6b
    postgresqlDatabase: sbl-mobile-api
    service:
      port: 5432
...
postgresql:
  enabled: true
  fullnameOverride: postgresq
...
pgadmin4:
  serverDefinitions:
  #defined in _helpers.tpl - "pgadmin.serverDefinitions"
    enabled: true
  extraSecretMounts:
  - name: pgpassfile
    secret: pgpassfile
    subPath: pgpassfile
    mountPath: "/pgpass"
    readOnly: true
  extraInitContainers: |
    - name: pgpass-permissions-init
      image: "docker.rdleas.ru/dpage/pgadmin4:4.29"
      command:
      - "/bin/ash"
      - "-c"
      - "/bin/mkdir -p /var/lib/pgadmin/storage/pgadmin && /bin/cp /pgpass /var/lib/pgadmin/storage/pgadmin/pgpass && /bin/chmod 0600 /var/lib/pgadmin/storage/pgadmin/pgpass"
      securityContext:
        runAsUser: 0
      volumeMounts:
      - mountPath: /pgpass
        name: pgpassfile
        readOnly: false
        subPath: pgpassfile
      - mountPath: /var/lib/pgadmin
        name: pgadmin-data
  persistentVolume:
    enabled: false
  securityContext:
    runAsUser: 0
    runAsGroup: 0
    fsGroup: 0

skaffold

anonymous@undisclosed.example.com (Anonymous) — Thu, 22 Apr 2021 09:44:05 +0000

https://skaffold.dev/
https://www.youtube.com/watch?v=0XXICbh9Bqs
https://softchris.github.io/pages/dotnet-dockerize.html#create-a-dockerfile
https://intellitect.com/docker-scaffold/
У меня есть три кластера (соотвествующие трем средам - dev, test, prod). В dev кластере должна происходить сборка и первичное тестирование сборок из ветки dev. В кластеры test и prod - должны выкатываться сборки из веток TEST и PROD соответственно.

Установка Shared-раннера GitLab в кластере kubernetes

Проще всего установить shared runner (то есть тот, который может использоваться любым проектом данной инсталляции GitLab) с помощью helm-чарта.
Создадим неймспейс:

kubectl create ns gitlab

Создадим секрет с корневым сертификатом, чтобы доверять инсталляции GitLab. Имя записи в секрете должна быть hostname.crt, где hostname - это имя хоста GitLab (gitlab.domain.local):

kubectl create secret generic -n gitlab ca-cert --from-file=gitlab.domain.local.crt=./CA.cer

Для того, чтобы раннер смог взаимодействовать с GitLab ему нужно передать пару параметров - адрес инсталляции GitLab и registration token.
Чтобы получить registration token идем в Admin Area → Runners и там берем строчку registration token, а затем подствляем в файл с values для чарта:

cat <<EOF > ./gitlab-runner-settings.yaml
image: gitlab/gitlab-runner:alpine-v13.8.0
runnerRegistrationToken: "dqjNDHQsum1zW1gVmtXc"
logLevel: debug
runners:
  privileged: true
  config: |
    [[runners]]
      [runners.kubernetes]
        image = "docker:dind"
  helpers:
    image: "gitlab/gitlab-runner-helper:x86_64-bleeding"
gitlabUrl: https://gitlab.domain.local/
certsSecretName: ca-cert
EOF

Устанавливаем GitLabRunner

helm repo add gitlab https://charts.gitlab.io
helm upgrade --install gitlab-runner-shared  -n gitlab -f ./gitlab-runner-settings.yaml gitlab/gitlab-runner

Дадим прав раннеру в кластере (то есть дадим прав дефолтной ServiceAccount в неймспейсе gitlab):

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: "ClusterRoleBinding"
metadata:
  name: gitlab-runner-admin
  namespace: gitlab
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: "ClusterRole"
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: default
  namespace: gitlab
EOF

В итоге - данная конфигурация позволит запускать раннер в кластере и позволит раннеру деплоить собранное. Не забываем, что речь иде о dev-кластере.

Настройка CI/CD на базе GitLab и Skaffold

Настройка проекта в GitLab

Включаем CI/CD для проекта - Settings → General → Visibility, project features, permissions → Pipelines
Настраиваем переменные - Settings → CI/CD → Variables. Нужно добавить DOCKER_REGISTRY_URL и конфиги для кластеров (переменные KUBECONFIG_PROD и KUBECONFIG_TEST), отличных от того, где работает раннер (в своем кластере раннер имеет права). Если docker registry требует аутентифиуации, то добавляем переменные DOCKER_REGISTRY_LOGIN и DOCKER_REGISTRY_PASS и расскоментируем в .gitlab-ci.yaml соответствующие строчки.

.gitlab-ci.yml

services:
#  - name: docker.rdleas.ru/docker:dind
# Последнюю версию dind (20+) не удается использовать из-за ошибки: https://github.com/containerd/containerd/issues/4837
# Нужно обновлять container.d на хостах
# В остальном - всё уже готово. 
  - name: docker.rdleas.ru/docker:19-dind
    command: 
      - /bin/sh
      - -c
      - |
        openssl s_client -showcerts -connect docker.rdleas.ru:443 </dev/null 2>/dev/null | awk '/BEGIN/ { i++; } /BEGIN/, /END/ { print }' > /usr/local/share/ca-certificates/ca.crt
        update-ca-certificates
        unset DOCKER_TLS_CERTDIR
        dockerd-entrypoint.sh

stages:
  - build

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_TLS_CERTDIR: ""
  DOCKER_HOST: tcp://0.0.0.0:2375

build:
  image:
    name: docker.rdleas.ru/k8s-skaffold/skaffold:v1.19.0
  stage: build
#  before_script:
#    - docker login -u `echo $DOCKER_REGISTRY_LOGIN` -p `echo $DOCKER_REGISTRY_PASS` `echo $DOCKER_REGISTRY_URL`
#https://skaffold.dev/docs/references/cli/
  script:
    - | 
      openssl s_client -showcerts -connect ${DOCKER_REGISTRY_URL}:443 </dev/null 2>/dev/null | awk '/BEGIN/ { i++; } /BEGIN/, /END/ { print }' > /usr/local/share/ca-certificates/ca.crt
      update-ca-certificates
      env
      echo "waiting for the DinD..."
      timeout 60 bash -c 'until printf "" 2>>/dev/null >>/dev/tcp/$0/$1; do sleep 1; done' 0.0.0.0 2375
      if [ "$CI_COMMIT_BRANCH" = "DEV" ]; then
        skaffold run -f skaffold-run.yaml --default-repo ${DOCKER_REGISTRY_URL}/vrm
      else
        skaffold build -f skaffold-build.yaml
      fi

Что тут прроисходит?

service: - эта инструкция запускает некую сущность (доступную по сети из скрипта для сборки). У гитлаба написано, что изначально так запускали БД. Теперь так запускаем docker и в дальнейшем передаем ему Dockerfile для сборки. Для того, чтобы этот сервис доверял нашим сертификатам - мы сначала добавляем сертификат в доверенные, а затем стартуем штатный Entrypoint.
stages: - список этапов конвейера, которые будут объявлены позднее.
variables: - список переменных среды, которые будут добавлены к другим переменным и доступны в контейнерах, которые будут запускаться в дальнейшем.
build: - собственно описание на данный момент единственной стадии конвейера. В ней мы стартуем контейнер skaffold, выполняем before_script, который логинится в приватный Docker Registry. Логин, пароль и url этого registry заданны в настройках проекта GitLab в виде Variables. Конструкции вида
```
`echo $DOCKER_REGISTRY_LOGIN`
```
сделаны для того, чтобы избежать ошибки:
```
cannot perform an interactive login from a non TTY device
```
Дальше - сам скрипт script. В нем тоже добавляется в доверенные сертификат нашего registry, а затем запускается skaffold с параметром run, который выполняет все стадии конвейера - сборку (а в процессе сборки запускается и тестирование) и деплой с помощью чарта.

skaffold.yaml

Тут происходит вот что.
Как понятно из манифеста - это Config для skaffold. Полное описание всего этого доступно https://skaffold.dev/docs/references/yaml/.
Итак. С точки зрения skaffold, работающего в контейнере, мы выполняем сборку локально, на что указывает тег local: {}.
Мы собраем артефакт с помощью клиента докера (тег docker), который будет общаться с сервером Docker, который является запущенным ранее service: и доступен нам благодаря объявленной переменной среды DOCKER_HOST.
Так вот этому докеру будет передан Dockerfile, путь к которому задан с помощью тега dockerfile: относительно пути context:.
А после сборки мы выкатываем релиз с помощью helm (который будет запущен из контейнера skaffold) в тот кластер на котором работает наш runner. Подробнее о том как скаффолд работат с кластером - тут https://skaffold.dev/docs/environment/kube-context/#kubeconfig-selection

apiVersion: skaffold/v2beta11
kind: Config
build:
  local: {}
  tagPolicy:
    envTemplate:
      template: "{{.CI_COMMIT_BRANCH}}"
  artifacts:
  - image: vrm
    context: .
    docker:
      dockerfile: Dockerfile
      buildArgs:
        CI_COMMIT_SHORT_SHA: '{{.CI_COMMIT_SHORT_SHA}}'
deploy:
  helm:
    releases: 
    - name: vrm
      chartPath: chart/
      namespace: vrm
      valuesFiles:
        - '{{.VALUES}}'
      artifactOverrides:
        image: vrm

Dockerfile

#https://docs.docker.com/engine/examples/dotnetcore/
FROM docker.rdleas.ru/amd64/maven:3.6.3-jdk-11 as builder
WORKDIR /app
COPY . .
RUN mvn -gs /app/.m2/settings.xml -Pnexus clean compile test-compile \
 && mvn -gs /app/.m2/settings.xml -Pnexus package

FROM docker.rdleas.ru/openjdk:11.0.10-jre-buster
ENV CI_COMMIT_SHORT_SHA=$CI_COMMIT_SHORT_SHA
WORKDIR /app
COPY --from=builder /app/. ./
CMD ["/usr/local/openjdk-11/bin/java", "-jar", "/app/target/vrm-1.0.0-SNAPSHOT.jar"]

Тут у нас двухстадийная сборка (multistage).
Сначала мы запускаем контейнер maven, который получает псевдоним builder, который выкачивает зависимости из локальной proxy-репы maven-central на базе nexus (директория .m2 с файлом settings.xml лежит в репозитории проекта). А далее мы собираем второй контейнер на базе образа OpenJDK JRE, в который копируем файлики, полученные в результате работы первого контейнера-билдера.

Настройка деплоя во внешний кластер

План такой:

создаем неймспейс, в который будем деплоить релиз с помощью helm-чарта
создаем ServiceAccount, который будет иметь права на все объекты в данном неймспейсе.
Создаем фалик KUBECONFIG, который мы передадим skaffold и с помощью которого будем обращаться к кластеру.
Созданный файлик KUBECONFIG кодируем в base64 и помещаем в переменную окружения проекта, чтобы передать его skaffold.

переключаемся на контекст тестового кластера:

kubectl config use-context test

Создаем неймспейс:

kubectl create ns vrm

Создаем ServiceAccount. Я создам его в неймспейсе kube-system:

kubectl create sa -n kube-system vrm-ns-admin

Дадим этой SA права в неймспейсе vrm:

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: vrm-ns-admin
  namespace: vrm
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: "RoleBinding"
metadata:
  name: vrm-ns-admin
  namespace: vrm
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: "Role"
  name: vrm-ns-admin
subjects:
- kind: ServiceAccount
  name: vrm-ns-admin
  namespace: kube-system
EOF

Дальше получаем имя токена:

TOKEN_NAME=`kubectl get secret -n kube-system -o name | grep vrm-ns-admin-token`

и его содержимое:

TOKEN=`kubectl get $TOKEN_NAME -n kube-system -o "jsonpath={.data.token}" | base64 -d`

а также корневой сертификат кластера:

TOKEN_CA=`kubectl get $TOKEN_NAME -n kube-system -o "jsonpath={.data['ca\.crt']}"`

и URL для control plane:

CONTROL_PLANE=`kubectl cluster-info | grep 'Kubernetes control plane' | awk '{print $NF}' | sed -r "s/[[:cntrl:]]\[([0-9]{1,3};)*[0-9]{1,3}m//g"`

И, наконец, генерируем собственно сам KUBECONFIG:

cat <<EOF > ./vrm-admin-kubeconfig
apiVersion: v1
kind: Config
preferences: {}
# Define the cluster
clusters:
- cluster:
    certificate-authority-data: $TOKEN_CA
    server: $CONTROL_PLANE
  name: cluster

# Define the user
users:
- name: vrm-ns-admin
  user:
    as-user-extra: {}
    client-key-data: $TOKEN_CA
    token: $TOKEN

# Define the context: linking a user to a cluster
contexts:
- context:
    cluster: cluster
    namespace: vrm
    user: vrm-ns-admin
  name: vrm

# Define current context
current-context: vrm
EOF

Проверяем, что полученный kubeconfig работает:

KUBECONFIG=./vrm-admin-kubeconfig kubectl get po -n vrm

Теперь - добавляем содержимое этого файла в свойтсвах проекта в переменную типа File. В итоге -содержимое файла будет доставлено в контейнер skaffold в виде временного файла, а её значение будет указать на расположение этого файла. А gitlab-ci.yml станет такой:

services:
#  - name: docker.rdleas.ru/docker:dind
# Последнюю версию dind (20+) не удается использовать из-за ошибки: https://github.com/containerd/containerd/issues/4837
# Нужно обновлять container.d на хостах
# В остальном - всё уже готово. 
  - name: docker.rdleas.ru/docker:19-dind
    command: 
      - /bin/sh
      - -c
      - |
        openssl s_client -showcerts -connect docker.rdleas.ru:443 </dev/null 2>/dev/null | awk '/BEGIN/ { i++; } /BEGIN/, /END/ { print }' > /usr/local/share/ca-certificates/ca.crt
        update-ca-certificates
        unset DOCKER_TLS_CERTDIR
        dockerd-entrypoint.sh

stages:
  - build

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_TLS_CERTDIR: ""
  DOCKER_HOST: tcp://0.0.0.0:2375

build:
  image:
    name: docker.rdleas.ru/k8s-skaffold/skaffold:v1.19.0
  stage: build
  before_script:
    - docker login -u `echo $DOCKER_REGISTRY_LOGIN` -p `echo $DOCKER_REGISTRY_PASS` `echo $DOCKER_REGISTRY_URL`
#https://skaffold.dev/docs/references/cli/
  script:
    - | 
      openssl s_client -showcerts -connect ${DOCKER_REGISTRY_URL}:443 </dev/null 2>/dev/null | awk '/BEGIN/ { i++; } /BEGIN/, /END/ { print }' > /usr/local/share/ca-certificates/ca.crt
      update-ca-certificates
      env
      echo "waiting for the DinD..."
      timeout 60 bash -c 'until printf "" 2>>/dev/null >>/dev/tcp/$0/$1; do sleep 1; done' 0.0.0.0 2375
      case $CI_COMMIT_BRANCH in
        DEV)      
          VALUES="chart/values_dev.yaml" skaffold run -f skaffold-run.yaml --default-repo ${DOCKER_REGISTRY_URL}/vrm
        ;;
        TEST)
          VALUES="chart/values_test.yaml" \
          KUBECONFIG=$KUBECONFIG_TEST \
          skaffold run -f skaffold-run.yaml \
          --default-repo ${DOCKER_REGISTRY_URL}/vrm
        ;;
        PROD)
          KUBECONFIG=$KUBECONFIG_PROD \
          VALUES="chart/values_prod.yaml" \
          skaffold run -f skaffold-run.yaml \
          --default-repo ${DOCKER_REGISTRY_URL}/vrm
        ;;
        *)
          skaffold build -f skaffold-build.yaml
        ;;
      esac

teamcity_gitlab_merge_pull_requests

anonymous@undisclosed.example.com (Anonymous) — Mon, 18 Sep 2023 12:39:38 +0000

Проблема

Мне необходимо реализовать интеграцию Merge Requests из GitLab с билдами Тимсити.
Нужно чтобы:

при создании MR в GitLab билдился собственно код из Merge Request'а
При удачном/неудачном билде Teamcity оповещал GitLab и красил кнопочку в зеленый или красный цвет - разрешая или запрещая собственно Merge.

Что я делаю

VCSRoot в проекте со следующим branchSpecs:
```
+:refs/(merge-requests/*)/head
-:refs/heads/develop
```
То есть - собираем все ветки MR, но не собираем дефолтную.
В buildType прописываю параметр, чтобы номер MR был доступен в билде в виде env-переменной со значением merge-requests/X:
```
param("env.CI_MR_BRANCH", "%teamcity.build.branch%")
```

И дальше, сборочный скрипт должен выполнить Approve с помощью https://docs.gitlab.com/ee/api/merge_request_approvals.html#approve-merge-request .

CI_PROJECT_ID=`curl -s -XGET -H "Content-Type: application/json" --header "PRIVATE-TOKEN: $GITLAB_TOKEN" https://gitlab.com/api/v4/projects/<YOUR-NAMESPACE>%2F<YOUR-PROJECT-NAME> | jq '.id'`
MERGE_REQUEST_IID=`echo ${CI_MR_BRANCH} | cut -d'/' -f2`
curl -f -s -XPOST -H "Content-Type: application/json" --header "PRIVATE-TOKEN: $GITLAB_TOKEN" https://gitlab.example.com/api/v4/projects/${CI_PROJECT_ID}/merge_requests/${MERGE_REQUEST_IID}/approve

Альтернативный вариант - GitLab External Status Check - https://about.gitlab.com/blog/2021/10/04/how-to-status-checks/

terrafrom

anonymous@undisclosed.example.com (Anonymous) — Mon, 12 Dec 2022 11:12:53 +0000

Error - key unmarshal fail

Error: key unmarshal fail: invalid character '-' in numeric literal

При извользовании провайдера yandex-cloud столкнулся с такой ошибкой, которая указывала на строку в файлике, где объявлен сам провайдер:

provider "yandex" {
  cloud_id   = var.yc_cloud_id
  folder_id  = var.yc_folder_id
}

Но не ведителсь!! Это глюк терраформа! Проблема была в авторизационном ключе! Он просто не подходил!

tools_bash_completition

anonymous@undisclosed.example.com (Anonymous) — Mon, 31 Aug 2020 08:04:38 +0000

helm completion bash | sudo tee /etc/bash_completion.d/helm
kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl

инструменты

anonymous@undisclosed.example.com (Anonymous) — Thu, 28 May 2020 08:21:15 +0000

Трассировка

Zipkin
Jaeger

Требуется доработка приложений

настройка_оболочки_для_удобной_работы

anonymous@undisclosed.example.com (Anonymous) — Fri, 01 Dec 2023 08:54:11 +0000

Настройка редактора секретов kubernetes

sudo apt-get -y install python3-pip python-pip
sudo pip install PyYaml
sudo pip3 install PyYaml
sudo wget https://raw.githubusercontent.com/lbolla/kube-secret-editor/master/kube-secret-editor.py -O /usr/local/bin/kube-secret-editor.py
sudo chmod a+x /usr/local/bin/kube-secret-editor.py
alias kedit-secret="EDITOR=nano KUBE_EDITOR=/usr/local/bin/kube-secret-editor.py kubectl edit secret"
sudo awk -v line='alias kedit-secret="EDITOR=nano KUBE_EDITOR=/usr/local/bin/kube-secret-editor.py kubectl edit secret"' 'FNR==NR && line==$0{f=1; exit} END{if (!f) print line >> FILENAME}' /etc/bash.bashrc

Настройка дефолтного редактора kubernetes

sudo awk -v line='export KUBE_EDITOR="/bin/nano"' 'FNR==NR && line==$0{f=1; exit} END{if (!f) print line >> FILENAME}' /etc/bash.bashrc

Настройка автозавршения команд kubectl

sudo awk -v line='source <(kubectl completion bash)' 'FNR==NR && line==$0{f=1; exit} END{if (!f) print line >> FILENAME}' /etc/bash.bashrc

Название ветки git в комндной строке

В ~/.bashrc добавляем такое:

parse_git_branch() {
     git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}
export PS1="\u@\h \[\e[32m\]\w \[\e[91m\]\$(parse_git_branch)\[\e[00m\]$ "

Или одной строкой:

grep parse_git_branch ~/.bashrc || cat >> ~/.bashrc <<EOF

parse_git_branch() {
     git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}
export PS1="\u@\h \[\e[32m\]\w \[\e[91m\]\\\$(parse_git_branch)\[\e[00m\]$ "
EOF

почитать

anonymous@undisclosed.example.com (Anonymous) — Tue, 21 Apr 2020 17:41:27 +0000

Team Topologies