Наша компания занимается обслуживанием серверов. Мониторинг для нас — сверхкритическая система, его отказ может привести к большим финансовым потерям. Отслеживать физическую доступность мониторинга может другая система мониторинга, а вот логические ошибки…
Расскажу историю одной ошибки, какие выводы мы сделали, и как изменили подход к системе мониторинга. Строчек кода не будет, речь пойдет про идеологию. Кому интересно, добро пожаловать подкат.
20.10.2017 я посетил конференцию DevOps в Питере и описал свои впечатления. Не рассчитывайте на хардкор, реальные примеры в духе «как внедрить DevOps в компании за 5 дней» или бесконечные осанны Docker, под катом их нет.
PostgreSQL для хипстеров, бэкенд "Модульбанка" и другое.
14 октября в солнечном городе Уфа прошла конференция UFADEVCONF.
Это первое мероприятие в Уфе такого масштаба, его организовало уфимское сообщество разработчиков Ufacoder и компания «Открытый регион». Секции докладов — Backend, Frontend, Mobile, Common.
Предлагаем обзор конференции и самых интересных докладов секции Backend.
Итак, у вас есть кластер Kubernetes, а для проброса внешнего трафика сервисам внутри кластера вы уже настроили Ingress-контроллер NGINX, ну, или пока только собираетесь это сделать. Класс!
Я тоже через это прошел, и поначалу все выглядело очень просто: установленный NGINX Ingress-контроллер был на расстоянии одного helm install. А затем оставалось лишь подвязать DNS к балансировщику нагрузки и создать необходимые Ingress-ресурсы.
Спустя несколько месяцев весь внешний трафик для всех окружений (dev, staging, production) направлялся через Ingress-серверы. И все было хорошо. А потом стало плохо.
Все мы отлично знаем, как это бывает: сначала вы заинтересовываетесь этой новой замечательной штукой, начинаете ей пользоваться, а затем начинаются неприятности.
По мере взросления и стабилизации экосистемы Docker связанные с безопасностью этого продукта темы привлекают все больше внимания. При проектировании инфраструктуры невозможно избежать вопроса обеспечения безопасности Docker.
В Docker уже встроено несколько замечательных средств обеспечения безопасности:
Docker-контейнеры минимальны: один или несколько работающих процессов, только необходимое программное обеспечение. Это снижает вероятность пострадать от уязвимостей в ПО.
Docker-контейнеры выполняют специфическую задачу. Заранее известно, что должно выполняться в контейнере, определены пути к директориям, открытые порты, конфигурации демонов, точки монтирования и т. д. В таких условиях проще обнаружить какие-либо связанные с безопасностью аномалии. Этот принцип организации систем идет рука об руку с микросервисной архитектурой, позволяя значительно уменьшить поверхность атаки.
Docker-контейнеры изолированы как от хоста, так и от других контейнеров. Этого удается добиться благодаря способности ядра Linux изолировать ресурсы с помощью cgroups и namespaces. Но есть серьезная проблема — ядро приходится делить между хостом и контейнерами (мы еще вернемся к этой теме чуть позже).
Однако в основанных на Docker системах есть и слабые места. В этой статье мы как раз о них и поговорим, рассмотрев 7 проблем безопасности Docker.
Вы наверняка знаете, что в Postgres есть материализованные представления (materialized views) и обертки сторонних данных (foreign data wrappers, FDW). Материализованные представления позволяют материализовывать запросы и обновлять их по требованию. Обертки сторонних данных предоставляют функциональность загрузки данных из внешних источников, таких как, например, NoSQL-хранилища или другие серверы Postgres.
Вероятно, что вариант использования материализованных представлений совместно с обертками сторонних данных вы еще не рассматривали. Материализованные представления ускоряют доступ к данным: результаты запросов сохраняются и отпадает необходимость выполнять их еще раз. Доступ к сторонним данным через FDW может быть довольно медленным, поскольку они находятся в других системах. Объединив эти функции, можно в итоге получить быстрый доступ к сторонним данным.
Сетевые политики (Network Policies) — это новая функциональность Kubernetes, которая за счет создания брандмауэров позволяет настроить сетевое взаимодействие между группами подов и других узлов сети. В этом руководстве я постараюсь объяснить особенности, не описанные в официальной документации по сетевым политикам Kubernetes.
Функциональность сетевых политик стабилизировалась в Kubernetes 1.7. В этой статье их работа объясняется в теории и на практике. При желании вы можете сразу перейти к репозиторию с примерами kubernetes-networkpolicy-tutorial или к документации.
В этой статье я расскажу о том, как мы управляем секретами в Kubernetes-инфраструктуре BaseCRM.
Наша цель — использование Helm Charts в Kubernetes-кластерах BaseCRM с минимальными усилиями, подразумевающими управление лишь значениями параметров и секретами. В Helm или Kubernetes нет официального инструмента управления секретами, и мы решили это исправить.
Мне очень нравится Terraform.
Помимо CloudFormation для AWS и OpenStack Heat, это один из самых полезных инструментов с открытым исходным кодом, обеспечивающих развертывание и настройку инфраструктуры на любой платформе. Однако есть один способ работы с Terraform, который меня беспокоит:
terraform plan # «Выглядит нормально; в работу!» — подумал инженер.
terraform applyМожет, это и не проблема, если вы разворачиваете софт на одной стойке в дата-центре или тестируете учетную запись AWS с ограниченными правами. В такой ситуации навредить достаточно сложно.
А если развертывание производится из-под всевидящего и всемогущего production-аккаунта или охватывает дата-центр целиком? Мне кажется, это весьма рискованно.
Интеграционное и юнит-тестирование способно решить эту проблему. Вы, наверное, спросите: «Юнит-тестирование — это как для программ?» Да, то самое юнит-тестирование!
В этой статье мы немного поговорим о том, что такое интеграционное и юнит-тестирование, а также рассмотрим проблемы и используемые на практике стратегии тестирования инфраструктуры. Мы также затронем стратегии развертывания инфраструктуры, поскольку они связаны с тестированием. Несмотря на то что в статье присутствует достаточное количество кода, глубокие познания в программировании от читателей не требуются.
Клиентов и потенциальных сотрудников удивляет устройство нашей компании. Клиентов интересует, почему наши услуги стоят так дешево/дорого, почему у нас адрес в Воронежской области, как при такой организации защищены их интересы? Админы хотят знать, куда их приглашают, почему все вакансии удаленные, почему список требований такой большой, а выполненное тестовое задание не означает автоматического найма.
В нескольких публикациях мы разберем, как устроена компания Southbridge. Пусть эта информация поможет вам определиться с поставщиком или с выбором места работы.
Первая статья будет об отношении к клиентам. Если вас интересует только работа админов, дождитесь второй.