DevOps
Статей о работе с PostgreSQL и её преимуществах достаточно много, но не всегда из них понятно, как следить за состоянием базы и метриками, влияющими на её оптимальную работу. В статье подробно рассмотрим SQL-запросы, которые помогут вам отслеживать эти показатели и просто могут быть полезны как пользователю.
Как сказал бы ныне великий классик собственная рабочая станция для ML это не роскошь, а средство для обучения. Да и к тому же арендованный сервер это не всегда, удобно быстро и безопасно.
Terraform за 15 дней (AWS/Yandex). День 1
Мы от простого к сложному, поднимем небольшую инфраструктуру на aws и Яндекс (актуальность последнего я думаю объяснять не нужно). Так что по итогу вы сможете сказать: “Я изучал terraform от простого к сложному”.
Я постараюсь добавить все необходимые ссылки на документации и доп. источники, так что вы сможете дополнить необходимые знания, но данный курс (если это можно так назвать) скорее рассчитан на тех, кто в общем знаком с облачными технологиями. Это не пособие по terraform. Цель - помочь новичкам в данном вопросе начать изучать IaC и облака в целом. Некий quick start в terraform.
У нас в Газпромбанке сложилась довольно интересная ситуация. Банк относительно недавно начал активно работать с розницей, которая как локомотив начала тянуть все внутрибанковское IT и менять характер работы всех подразделений.
Одна из главных наших проблем (впрочем, как и у многих) — долгие релизы, низкое качество кода, недоступность и нестабильность систем на тестовых полигонах. Но главное — интеграционные релизы. Когда несколько команд одновременно пытаются зарелизить свои доработки, нужно много времени и средств, чтобы синхронизировать всех. При этом каждый привносит новые баги, все начинают бегать кругами, спотыкаться, фиксить, перенакатывать… В итоге качество продукта низкое, а пользователь смотрит на это все с недоумением.
Как с этим всем бороться? Вот короткий рецепт от нас: избавиться от интеграционных релизов. Вообще. Собрать автономные, кросс-функциональные команды, каждая из которых будет выполнять свою задачу, не толкаясь локтями с другими. Для этого перепилить пайплайн, повысить инженерную культуру, ввести стандарты и так далее. Подробнее — под катом.
Всем привет! Вот и я решил написать тут, да не просто статью, а серию статей в лайв формате. Тема - строительство своего дома, Умного дома.
Собственно, строительства будет минимум, а инженерки и её автоматизации поболее.
Строим Умный дом вместе ;)
Большой размер придомовой парковки не гарантирует, что вы легко и быстро найдете парковочное место, а чаще даже наоборот, при заезде на парковку может начаться приступ депрессии от того, что объехал парковку, потратил время, но в итоге место не нашёл. Как можно добавить в жизни чуть-чуть больше определённости, я опишу ниже.
Добрый день, меня зовут Евгений Кузаков.
В силу рода деятельности (я руководитель DevOps-практики) периодически встают задачи сайзинга оборудования для новых кластеров Заказчиков.
Обычно разработка начинается на кластерах разработки в недрах компании.
Все выкатки, естественно, происходят с ограничением ресурсов по ядрам и оперативной памяти. Это необходимо делать всегда - как для некритичных кластеров, так и продуктивных.
В противном случае будут наблюдаться как минимум следующие проблемы:
Туториалы делятся на две больших категории: либо "как нарисовать сову", либо подробно расписанные тысячи шагов в формате "напиши туториал для дурака - и только дурак захочет его читать".
Как какой из двух категорий относится эта статья — решать вам.
В этой статье вы увидите пошаговое создание cloud-native микросервиса на Amazon AWS, пригодное для "чтения с листа". Чтобы понять, что здесь происходит, не нужно разворачивать проект - достаточно обладать живым воображением и прочитать текст по диагонали. Если же вы всё-таки захотите повторить шаги, вам будут жизненно нужны знания вида, как создавать классы в IDE и что такое Spring.
Вначале мы напишем пару простых микросервисов на Spring Boot, докеризуем их, зальём в AWS, настроим красивые доменные имена и HTTPS, прикрутим логирование и мониторинг, Prometheus и Grafana. Это небольшое путешествие по всем кругам ада, из которого вы не вернетесь прежним.
Текст написан на основе текстов и демо-проекта microservice-customer за авторством @kamaruzzaman. Если вы потеряли нить повествования, всегда можно зайти на GitHub и найти весь код в пригодном для запуска виде. Если захочется закопаться в тему, то бро Дима Чуйко (@Teapot) написал вам ещё две части статьи "Микросервисы: от CRUD до Native Image" (раз, два).
Последняя важная оговорка. В этом гайде будут использоваться технологии Amazon и обычные дистрибутивы OpenJDK. Автор осознает, что мы живём в России, и возможно, вместо Amazon куда лучше подойдет что-то вроде SberCloud или MTS Cloud, а вместо обычного OpenJDK - Axiom JDK с сертификацией по ФСТЭК. Особенности российских технологий - тема для отдельной статьи. Если вы захотите таковую после чтения этого гайда - отметьтесь в комментариях.
Контролировать качество исходного кода как можно раньше в жизненном цикле проекта - хорошая практика. Давайте разберемся, как применять этот принцип в работе с Kubernetes.
В целом, компании всегда ищут способы увеличить свою продуктивность на всех уровнях: инфраструктура, люди, процессы и др. Зачастую продуктивность достигается за счет внедрения автоматизированных процессов для облегчения работы и увеличения темпов производства. Подобная автоматизация требует эволюции, адаптации или даже полной трансформации концептов, используемых ранее. Это включает в себя обеспечение и контроль политик безопасности.
В самом деле, с появлением новых методов работы, основанных на гибкости (вроде DevOps), некоторые принципы безопасности пришлось адаптировать к темпам развития и управления компонентами инфраструктуры. Сегодня одна из наиболее безопасных практик - это как можно раньше переместить эти контрольные точки в цепи интеграции, чтобы быстрее обнаруживать любые аномалии, заслуживающие особого внимания.
У вас есть кластер, в котором хочется разместить как можно больше рабочих сервисов и продуктов для внутреннего использования, ибо удобно: систему управления версиями, репозиторий Docker-образов, S3-хранилище, базы данных, тестовые среды и т.д. Но есть "но": многие из них, как например, репозиторий Docker-образов, могут работать только с использованием TLS. У вас есть два пути: получить сертификат от одного из сертификационных центров, платных или бесплатных, вроде Let's Encrypt, или сгенерировать самому. Устанавливать на каждого клиента сертификат нашего "левого" самопровозглашённого центра не хочется, поэтому самоподписанный сертификат отпадает. Денег платить каждый год не хочется, поэтому выбираем Let's Encrypt. Но и тут есть проблема (помимо необходимости автоматизации перевыпуска сертификата не реже раза в три месяца): внутренние сервисы нельзя выставлять в публичную сеть, а значит и HTTP-01 вариант подтверждения владения доменом нам недоступен. Остаётся только DNS-01 метод, который имеет свои подводные камни.
В данной статье я расскажу о своём опыте автоматизации выпуска/перевыпуска wildcard-сертификата для домена второго уровня (wildcard, чтобы два раза не вставать, но можно выпускать сертификаты и для каждого отдельного поддомена) для использования внутренними сервисами, расположенными в Kubernetes-кластере, с помощью cert-manager и бесплатного сервиса поддержки DNS-зон Яндекс.Коннект.
Недавно мы проводили вебинар «Обкафкился по полной. Фейлы с Apache Kafka». На нём спикер Всеволод Севостьянов, Engineering Manager в HelloFresh, поделился фейлами из личной практики, а ещё рассказал, как мастерски ходить по тонкому льду Kafka и прокачать свой бэкенд. Для тех, кто пропустил или предпочитает читать, а не смотреть, подготовили текстовый вариант.
Отслеживание изменённых данных (CDC) — это метод интеграции данных для обнаружения, захвата и передачи изменений, внесённых в источники данных базы данных.Как правило, интеграция данных на основе CDC состоит из следующих шагов:
Помните, как вы были студентами, и готовились к экзаменам по ночам?
Предлагаю вашему вниманию простую шпаргалку по SQL с теорией и практикой, которой вы сможете воспользоваться в любое время.
Изучите теорию на примерах и закрепите на 13 практических задачах по SQL.
В этой статье мы рассмотрим основные принципы миграции БД без даунтайма и дадим быстрые рецепты для наиболее распространенных случаев.
Привет, Хабр! Меня зовут Евгений Симигин, я занимаюсь внедрением DevOps-практик в Центре компетенций по разработке облачных и интернет-решений МТС Digital. А еще я – куратор практикумов docker и kubernetes на платформе rebrainme.com.
Практика показывает, что далеко не все инженеры знают о том, как шифровать секреты в своих репозиториях. Поэтому расскажу об инструментах helm-secrets, sops и vals, которые помогают быстро и просто решить эту задачу. Надеюсь, что после выхода моей статьи закоммиченных паролей в репах станет меньше :).
Приветствую всех Хабровчан. Сегодня говорим про Helm и то, как мы у себя в Nixys пришли к универсальному чарту, который стали использовать в своей работе как стандартный инструмент и почему это сделало нашу работу эффективнее.
Дисклаймер: Я написал такую статью, какую сам хотел бы прочитать полгода-год назад, когда мы стартовали миграцию в облако. Мне бы она здорово помогла сэкономить силы, время и нервы – надеюсь, теперь поможет кому-то ещё. Здесь нет исчерпывающей экспертизы, только немного моего опыта для конкретных условий и наработанные мною решения и инструменты.
Часто пользователи рассказывают о сбое базы данных по вине Out Of Memory Killer. Он завершает процессы PostgreSQL и остается причиной большинства отказов этой БД. Память на хост-компьютере может закончиться по нескольким причинам. Наиболее распространены из них четыре. Во-первых, может быть плохо настроена память на хост-компьютере. Во-вторых, могут быть ограничения глобальной переменной work_mem. Например, если у вас 32Гб RAM и work_mem=1Гб, то больше 32 соединений вы никогда не запустите. Каждое соединение PostgreSQL будет выделять этот размер памяти.
Третьей причиной будет большое количество подключений. Даже неактивное соединение может занимать значительный объем памяти. И наконец, другие программы тоже потребляют ресурсы, потому что для каждой из них этот компьютер является хостом.
Представляем вам перевод статьи от Jobin Augustine, который работает в Percona старшим инженером службы поддержки. Более 20-лет он был консультантом, архитектором, администратором и инструктором по PostgreSQL, Oracle и другим технологиям баз данных. Сегодня поговорим о том, как можно защититься от OOM с помощью HugePages и разберем насколько они важны и почему нужны.