Короткое сравнение разницы между использованием kops и EKS: https://medium.com/@Amet13/kops-eks-79a267f58d81
понедельник, 11 ноября 2019 г.
суббота, 19 октября 2019 г.
Перестаньте хранить корпоративные пароли в Google Docs или Slack
Довелось тут недавно заняться немного security, по долгу службы какое-то время назад нужно было часто людям выдавать различные доступы внутри корпоративной сети.
В статье описал, как обычно я генерю и храню свои пароли и как это делают люди.
Также описал, как можно легко в кубере развернуть PrivateBin внутри корпоративной сети:
https://medium.com/@Amet13/privatebin-369ffe5f4e6b
В статье описал, как обычно я генерю и храню свои пароли и как это делают люди.
Также описал, как можно легко в кубере развернуть PrivateBin внутри корпоративной сети:
https://medium.com/@Amet13/privatebin-369ffe5f4e6b
воскресенье, 29 сентября 2019 г.
Обзор GitHub Actions и Package Registry
На днях поковырял новые сервисы GitHub, написал статью на хабр: https://habr.com/en/post/468345/
Перевел сразу на medium: https://medium.com/@Amet13/gh-actions-package-registry-d29ceff4e6f4
Перевел сразу на medium: https://medium.com/@Amet13/gh-actions-package-registry-d29ceff4e6f4
понедельник, 19 августа 2019 г.
Как и зачем мы мигрировали Preply в Kubernetes
Написал статью о том, как мы мигранули нашу инфраструктуру в кубер: https://medium.com/preply-engineering/k8s-b22c298476cb
Заодно и на хабр перевел: https://habr.com/en/post/464465/
Заодно и на хабр перевел: https://habr.com/en/post/464465/
суббота, 27 июля 2019 г.
Вопросы на собеседовании на позицию DevOps-инженера которые задавал я
Я чуть больше года назад оставлял заметку о том, какие вопросы мне задавали на собеседованиях.
В последние несколько месяцев мне самому доводилось достаточно собеседовать людей, поэтому в этой заметке я расскажу какие вопросы задавал я и почему.
Техническое интервью с кандидатом у нас занимало примерно 1.5 часа.
Собеседование с применением обычной белой доски (whiteboard) и маркера. Мы не использовали схему вопрос-ответ, а само собеседование шло в виде беседы, по мере которой с каких-то общих тем мы углублялись в конкретные детали.
В первую очередь мы со своей стороны рассказывали, что у нас за продукт с технической точки зрения, что мы делаем по инфраструктурной части, как проиходит работа в команде платформы и взаимодействие с разработчиками и другими отделами. Объясняли кандидату почему мы сейчас ищем человека в команду, какие ближайшие планы по развитию команды и продукта с технической точки зрения, и т.д.
По резюме кандидата мы особо не спрашивали, но учитывали во внимание то, что если человек 5 лет работал с сетями и прочими цисками, то нет смысла спрашивать его про модель OSI и что такое пиринг VPC.
Первый часть с которой мы начинали, это попросили кандидата на доске нарисовать как он видит схему инфраструктуры какого-нибудь веб-проекта. Начиная с самого простенького что у нас просто есть инстанс или железный сервер (мы кстати рекомендовали привязываться к любому удобному облачному провайдеру или вообще bare-metal).
По мере роста инфраструктуры задавались наводящие вопросы по теме:
- как бы ты реализовывал балансинг на инстансах, автоскейлинг группу, и т.д.
- что бы ты делал если начинает расти нагрузка на базу, репликации, индексы, кеш, очереди
- если сломался сервер, как бы ты траблшутил все это
- зачем нужен CDN, как ходит трафик к твоему приложению, зашифрован ли он, на каком этапе происходит терминирование SSL
- как бы ты реализовывал бекапы
- какой мониторинг бы использовал и почему, когда стоит платить деньги за какой-нибудь datadog, а когда уже стоит завозить свой условный Prometheus-стек, то же самое касается логгинга
Вторая часть плавно переходила в понимание и огранизацию процесса CI/CD.
Как кандидат видит пайплайн, какие инструменты бы он использовал, как поддерживать адекватные косты для всего этого хозяйства (например юзать спот инстансы) и прочее.
Если у кандидата имелся опыт работы с Kubernetes задавали несколько вопросов по куберу, так как у нас его уже активно используют. Вопросы больше были из разряда:
- какие проблемы решает кубер, а какие нет
- в чем отличие контейнерной виртуализации от полной
- для чего придумали HELM и как его используют
Обычно этого было достаточно для понятия уровня кандидата. Но иногда если оставалось время, то могли спросить какой-то каверзный вопрос из разряда, где на жестком диске находится каталог /proc или как посмотреть нетстатом established UDP соединения.
В последние несколько месяцев мне самому доводилось достаточно собеседовать людей, поэтому в этой заметке я расскажу какие вопросы задавал я и почему.
Техническое интервью с кандидатом у нас занимало примерно 1.5 часа.
Собеседование с применением обычной белой доски (whiteboard) и маркера. Мы не использовали схему вопрос-ответ, а само собеседование шло в виде беседы, по мере которой с каких-то общих тем мы углублялись в конкретные детали.
В первую очередь мы со своей стороны рассказывали, что у нас за продукт с технической точки зрения, что мы делаем по инфраструктурной части, как проиходит работа в команде платформы и взаимодействие с разработчиками и другими отделами. Объясняли кандидату почему мы сейчас ищем человека в команду, какие ближайшие планы по развитию команды и продукта с технической точки зрения, и т.д.
По резюме кандидата мы особо не спрашивали, но учитывали во внимание то, что если человек 5 лет работал с сетями и прочими цисками, то нет смысла спрашивать его про модель OSI и что такое пиринг VPC.
Первый часть с которой мы начинали, это попросили кандидата на доске нарисовать как он видит схему инфраструктуры какого-нибудь веб-проекта. Начиная с самого простенького что у нас просто есть инстанс или железный сервер (мы кстати рекомендовали привязываться к любому удобному облачному провайдеру или вообще bare-metal).
По мере роста инфраструктуры задавались наводящие вопросы по теме:
- как бы ты реализовывал балансинг на инстансах, автоскейлинг группу, и т.д.
- что бы ты делал если начинает расти нагрузка на базу, репликации, индексы, кеш, очереди
- если сломался сервер, как бы ты траблшутил все это
- зачем нужен CDN, как ходит трафик к твоему приложению, зашифрован ли он, на каком этапе происходит терминирование SSL
- как бы ты реализовывал бекапы
- какой мониторинг бы использовал и почему, когда стоит платить деньги за какой-нибудь datadog, а когда уже стоит завозить свой условный Prometheus-стек, то же самое касается логгинга
Вторая часть плавно переходила в понимание и огранизацию процесса CI/CD.
Как кандидат видит пайплайн, какие инструменты бы он использовал, как поддерживать адекватные косты для всего этого хозяйства (например юзать спот инстансы) и прочее.
Если у кандидата имелся опыт работы с Kubernetes задавали несколько вопросов по куберу, так как у нас его уже активно используют. Вопросы больше были из разряда:
- какие проблемы решает кубер, а какие нет
- в чем отличие контейнерной виртуализации от полной
- для чего придумали HELM и как его используют
Обычно этого было достаточно для понятия уровня кандидата. Но иногда если оставалось время, то могли спросить какой-то каверзный вопрос из разряда, где на жестком диске находится каталог /proc или как посмотреть нетстатом established UDP соединения.
понедельник, 17 июня 2019 г.
Получаем wildcard SSL-сертификат в Kubernetes с помощью cert-manager
Короткая заметка о том как быстро поставить cert-manager в кубер, поднять ишуеры и насетапить креды в AWS для получения как обычного так и wildcard сертификата с помощью Let's Encrypt: https://medium.com/@Amet13/wildcard-k8s-4998173b16c8
Также узнал недавно о том, что есть такая штука как kubernetes-replicator, о ней я тоже вскольз упомянул.
Также узнал недавно о том, что есть такая штука как kubernetes-replicator, о ней я тоже вскольз упомянул.
суббота, 25 мая 2019 г.
DevOps Days Kyiv 2019
17-18 мая в Киеве прошла ежегодная конференция DevOps Days Kyiv.
Особенность конференции заключается в том, что доклады посвящены культуре девопса, а не техническим деталям.
Помимо основных докладов можно было выступить со своей темой (ignite talks).
Например были небольшие доклады про Terraform, БД, VictoriaMetrics, звезды на Github, организацию сети в амазоне и много других интересных докладов.
Помимо докладов, каждый мог предложить какую-либо тему для обсуждения в формате open space, некоторые из обсуждаемых тем второго дня:
Terraform и СУБД в Kuberentes также были на open space обсуждениях.
В общем конфа получилась интересная, как с организаторской точки зрения, так и со стороны докладов и качества материала.
Фото: https://www.facebook.com/pg/devopsdayskyiv/photos/?tab=album&album_id=402849030443211&ref=page_internal
Слайды презентации: https://www.slideshare.net/MykolaMarzhan/presentations
Видео докладов: https://www.youtube.com/playlist?list=PL_O8YSX8ckffzeV9mIBUQniaKFxGnPdYh
Особенность конференции заключается в том, что доклады посвящены культуре девопса, а не техническим деталям.
Помимо основных докладов можно было выступить со своей темой (ignite talks).
Например были небольшие доклады про Terraform, БД, VictoriaMetrics, звезды на Github, организацию сети в амазоне и много других интересных докладов.
Помимо докладов, каждый мог предложить какую-либо тему для обсуждения в формате open space, некоторые из обсуждаемых тем второго дня:
Terraform и СУБД в Kuberentes также были на open space обсуждениях.
В общем конфа получилась интересная, как с организаторской точки зрения, так и со стороны докладов и качества материала.
Фото: https://www.facebook.com/pg/devopsdayskyiv/photos/?tab=album&album_id=402849030443211&ref=page_internal
Слайды презентации: https://www.slideshare.net/MykolaMarzhan/presentations
Видео докладов: https://www.youtube.com/playlist?list=PL_O8YSX8ckffzeV9mIBUQniaKFxGnPdYh
воскресенье, 19 мая 2019 г.
Отправляем логи Kubernetes в AWS Elasticsearch Service
Написал небольшую статейку по поводу того, как можно отправлять логи кубера и в частности Nginx Ingress в AWS Elasticsearch Service: https://medium.com/@Amet13/sending-kubernetes-logs-to-amazon-elasticsearch-service-8fb8f18ac35d
В целом ничего сверхъестественного, в двух словах описал где можно разворачивать эластик и почему я использовал именно такой сетап. Также немного цифр по нагрузке и количеству логов.
В целом ничего сверхъестественного, в двух словах описал где можно разворачивать эластик и почему я использовал именно такой сетап. Также немного цифр по нагрузке и количеству логов.
воскресенье, 7 апреля 2019 г.
Отправляем метрики из AWS Cloudwatch в Prometheus с помощью prometheus-operator в Kubernetes
Добавляем права нашему пользователю AWS для чтения метрик:
Ну и наконец посмотрим сами метрики:
aws iam attach-group-policy \
--policy-arn arn:aws:iam::aws:policy/CloudWatchReadOnlyAccess \
--group-name kops-dev
Создаем values-файл для экспортера:
--policy-arn arn:aws:iam::aws:policy/CloudWatchReadOnlyAccess \
--group-name kops-dev
Создаем values-файл для экспортера:
cat << EOF > values-cloudwatch-exporter.yml
service:
annotations:
prometheus.io/scrape: "true"
EOF
Устанавливаем экспортер:
service:
annotations:
prometheus.io/scrape: "true"
EOF
Устанавливаем экспортер:
helm install stable/prometheus-cloudwatch-exporter \
--name prometheus-cloudwatch-exporter \
--namespace kube-system \
--set aws.aws_access_key_id=${AWS_ACCESS_KEY_ID} \
--set aws.aws_secret_access_key=${AWS_SECRET_ACCESS_KEY} \
-f values-cloudwatch-exporter.yml
Создаем values-файл для оператора:
--name prometheus-cloudwatch-exporter \
--namespace kube-system \
--set aws.aws_access_key_id=${AWS_ACCESS_KEY_ID} \
--set aws.aws_secret_access_key=${AWS_SECRET_ACCESS_KEY} \
-f values-cloudwatch-exporter.yml
Создаем values-файл для оператора:
cat << EOF > values-operator.yml
prometheus:
additionalServiceMonitors:
- name: prometheus-operator-cloudwatch
endpoints:
- port: http
path: /metrics
interval: 30s
namespaceSelector:
matchNames:
- kube-system
selector:
matchLabels:
app: prometheus-cloudwatch-exporter
serviceMonitors:
- name: ""
namespaceSelector:
any: true
EOF
Устанавливаем prometheus-operator с Alertmanager и Grafana:
prometheus:
additionalServiceMonitors:
- name: prometheus-operator-cloudwatch
endpoints:
- port: http
path: /metrics
interval: 30s
namespaceSelector:
matchNames:
- kube-system
selector:
matchLabels:
app: prometheus-cloudwatch-exporter
serviceMonitors:
- name: ""
namespaceSelector:
any: true
EOF
Устанавливаем prometheus-operator с Alertmanager и Grafana:
helm install stable/prometheus-operator \
--name prometheus-operator \
--namespace monitoring \
-f values-operator.yml
Идем в дашборд прометеуса на страницу Targets и проверяем наш новый таргет:
--name prometheus-operator \
--namespace monitoring \
-f values-operator.yml
Идем в дашборд прометеуса на страницу Targets и проверяем наш новый таргет:
Ну и наконец посмотрим сами метрики:
суббота, 9 марта 2019 г.
FOSDEM 2019
2-3 февраля мне удалось побывать на ежегодной конференции FOSDEM.
Конфа полностью бесплатная, проводилась на базе университета Брюсселя, примерно в часе пешком от центра Брюсселя.
Народу было много, гитхаб разливал кофеек бесплатно:
Докладов было очень много, но не всегда можно было попасть на те которые хочется из-за большого количества народу.
Помимо самих докладов, было множество интересных стендов, на некоторых даже можно было взять пивко за донат или сделать себе значок с логотипом Gentoo собственными руками:
Теперь пару слов о докладах, на которых я побывал (тут неполный список, только те что я сходу нашел):
- Deploying PostgreSQL on Kubernetes — ожидал услышать хардкора, но по факту рассказывалось про базовые вещи кубера и что постгрес можно деплоить ямликами, хелмом или оператором
- MySQL Replication - Advanced Features — Петр Зайцев рассказал об истории появления различных репликаций в MySQL, чем отличаются различные типы репли чтоикаций и т.д.
- Loki - Prometheus for logs — презентация тулзы для логов от создателей Grafana, выглядит круто, посмотрим как покажет себя на деле
- Introducing kubectl-trace — вроде что-то про трассировку в кубере, толком не смотрел доклад, так как в это время чинил стейджевый куберовский кластер :)
- Upcoming Kubernetes Storage features — TLDR: скоро можно будет PVC мувать между неймспейсами, клонировать PVC и создавать Populating PVC (т.е. при создании PVC сразу же на него например клонировать код из git-репозитория или скачивать файл по http, что-то на манер packer)
- PostgreSQL Goes to 11! — немного истории постгреса и обзор чейнджлога к 11 версии
- Netflix and FreeBSD — доклад о том, как Netflix поддерживают свою кодовую базу FreeBSD, почему и как они гоняют большой траффик на своих CDN с помощью FreeBSD
- The Cloud is Just Another Sun — история о том, как было раньше с серверами, как сейчас все в облаках и что надо делать дальше
- 2019 - Fifty years of Unix and Linux advances — maddog интересно рассказал, как разивался Unix, GNU, Linux, open source, в интересной форме
Конфа полностью бесплатная, проводилась на базе университета Брюсселя, примерно в часе пешком от центра Брюсселя.
Народу было много, гитхаб разливал кофеек бесплатно:
Помимо самих докладов, было множество интересных стендов, на некоторых даже можно было взять пивко за донат или сделать себе значок с логотипом Gentoo собственными руками:
- Deploying PostgreSQL on Kubernetes — ожидал услышать хардкора, но по факту рассказывалось про базовые вещи кубера и что постгрес можно деплоить ямликами, хелмом или оператором
- MySQL Replication - Advanced Features — Петр Зайцев рассказал об истории появления различных репликаций в MySQL, чем отличаются различные типы репли чтоикаций и т.д.
- Loki - Prometheus for logs — презентация тулзы для логов от создателей Grafana, выглядит круто, посмотрим как покажет себя на деле
- Introducing kubectl-trace — вроде что-то про трассировку в кубере, толком не смотрел доклад, так как в это время чинил стейджевый куберовский кластер :)
- Upcoming Kubernetes Storage features — TLDR: скоро можно будет PVC мувать между неймспейсами, клонировать PVC и создавать Populating PVC (т.е. при создании PVC сразу же на него например клонировать код из git-репозитория или скачивать файл по http, что-то на манер packer)
- PostgreSQL Goes to 11! — немного истории постгреса и обзор чейнджлога к 11 версии
- Netflix and FreeBSD — доклад о том, как Netflix поддерживают свою кодовую базу FreeBSD, почему и как они гоняют большой траффик на своих CDN с помощью FreeBSD
- The Cloud is Just Another Sun — история о том, как было раньше с серверами, как сейчас все в облаках и что надо делать дальше
- 2019 - Fifty years of Unix and Linux advances — maddog интересно рассказал, как разивался Unix, GNU, Linux, open source, в интересной форме