Начальник отдела разработки ПО
GitLab можно использовать как первоклассный инструмент GitOps, и здесь мы покажем как. Это пятое практическое руководство из серии, посвящённой разным задачам пользователей, включая подготовку базовой инфраструктуры, управление ей и развёртывание поверх неё различных сторонних и кастомных приложений.
Здесь мы посмотрим, как получить доступ к кластеру Kubernetes с помощью GitLab CI/CD и зачем это нужно, если вы взяли курс на GitOps.
В этой статье на примере простого приложения будут описаны подготовка и развертывание инфраструктуры для локальной разработки с Kubernetes и последующий запуск проекта в этом окружении.
Зачем это может понадобиться? Предоставляя услуги поддержки инфраструктуры нашим клиентам, нам часто приходится искать баланс между эффективностью и затраченными ресурсами. Когда есть потребность в нескольких рабочих окружениях для разработчиков (stage, dev, test, review и т.п.), как правило, ограничивающим фактором в их реализации являются деньги. Поэтому для решения такой задачи — в дополнение к динамическим окружениям (или вместо них) — задействуются локальные окружения прямо на рабочих местах разработчиков, о которых и пойдет речь далее.
В этой статье мы рассмотрим, как настроить реестр образов GitLab Container Registry, находящийся за обратным прокси сервером NGINX. Предполагается, что у вас уже установлен GitLab с помощью пакета Omnibus. Согласно документации, Container Registry можно настроить на том же домене, на котором работает сам GitLab, но в случае работы GitLab за прокси сервером, необходимо завести отдельный домен для реестра образов, чтобы избежать конфликта доменных имен при настройке виртуальных хостов в GitLab Nginx.
Реестр образов будет доступен по адресу: registry.example.com. Добавляем А запись для домена реестра в DNS. Приводим конфиг виртуального хоста на сервере обратного прокси к следующему виду:
Это продолжение предыдущего туториала про командную разработку с использованием GitLab. Фокус предыдущей статьи был на организации непрерывной поставки в работе команды. В этой статье мы уделим основное внимание именно практическим действиям необходимым для развёртывания из GitLab в Kubernetes.
А именно мы возьмём максимально простое но достаточно содержательное приложение на React.js, докеризуем его, затем развернём в Kubernetes локально при помощи Docker Desktop. После этого развернём его уже на Google Cloud Platform (GCP), и завершим разработкой CI/CD конвейера в GitLab для публикации нашего приложения в Google Kubernetes Engine.
Желательны но необязательны базовые знания
В дальнейшем мы сделаем следующее.
На сегодняшний день это один из, или же самый известный способ автоматического анализа кода и его ревью. Популярностью он обязан тому, что этот сервис бесплатен и доступен, а так же для его установки не требуется много усилий. Интерфейс выглядит современно и понятно. Sonarqube, хоть и написан на java, не ест много ресурсов :)
Эта статья использует устаревший и не самый рациональный подход, на данный момент не могу его рекомендовать к использованию. Рекомендую к прочтению следующую статью.
В данной статье я расскажу о своём опыте "заворачивания" Laravel-приложения в Docker-контейнер да так, что бы и локально с ним могли работать frontend и backend разработчики, и запуск его на production был максимально прост. Так же CI будет автоматически запускать статические анализаторы кода, phpunit-тесты, производить сборку образов.
"А в чём, собственно, сложность?" — можешь сказать ты, и будешь отчасти прав. Дело в том, что этой теме посвящено довольно много обсуждений в русскоязычных и англоязычных комьюнити, и почти все изученные треды я бы условно разделил на следующие категории:
fedora:latest (~230 Mb), ставлю в него все сервисы (nginx, бд, кэш, etc), запускаю всё супервизором внутри". Тоже отлично, прост в запуске, но как на счёт идеологии "один контейнер — один процесс"? Как обстоят дела с балансировкой и управлением процессами? Как же размер образа?Для нетерпеливых — ссылка на репозиторий, склонировав который ты сможешь запустить Laravel-приложение одной командой. Так же не составит труда его запустить на том же rancher, правильно "слинковав" контейнеры, или использовать продуктовый вариант docker-compose.yml как отправную точку.
В PostgreSQL начиная с очень давних времён аж версии 8.0 вышедшей в далёком 2005 году для восстановления в определённую точку времени использовался специальный файл конфигурации recovery.conf. Этот же файл впоследствии стал использоваться для режима standby и потоковой репликации.
Небольшая инструкция о том, как используя Keycloak можно связать Kubernetes с вашим LDAP-сервером и настроить импорт пользователей и групп. Это позволит настраивать RBAC для ваших пользователей и использовать auth-proxy чтобы защитить Kubernetes Dashboard и другие приложения, которые не умеют производить авторизацию самостоятельно.
DevOps- и SRE-инженеры уже, наверное, не раз слышали о Prometheus.
Prometheus был создан на SoundCloud в 2012 году и с тех пор стал стандартом для мониторинга систем. У него полностью открытый исходный код, он предоставляет десятки разных экспортеров, с помощью которых можно за считанные минуты настроить мониторинг всей инфраструктуры.
Prometheus обладает очевидной ценностью и уже используется новаторами в отрасли, вроде DigitalOcean или Docker, как часть системы полного мониторинга.
Что такое Prometheus?
Зачем он нужен?
Чем он отличается от других систем?
Если вы совсем ничего не знаете о Prometheus или хотите лучше разобраться в нем, в его экосистеме и всех взаимодействиях, эта статья как раз для вас.
В последнее время Jupyter Notebook стал очень популярен среди специалистов Data Science, став де-факто стандартом для быстрого прототипирования и анализа данных. В Netflix, стараемся раздвинуть границы его возможностей еще дальше, переосмысливая то, чем может быть Notebook, кем может быть использован, и что они могут могут с ним делать. Мы вкладываем много сил, чтобы воплотить наше видение в реальность.
В данной статье мы хотим рассказать почему считаем что Jupyter Notebooks настолько привлекательным и что вдохновляет нас на этом пути. Кроме того, опишем компоненты нашей инфраструктуры и сделаем обзор новых способов использования Jupyter Notebook в Netflix.
Примечание от переводчика: осторожно, много текста и мало картинок
Это практическое пособие познакомит вас c Ansible. Вам понадобится виртуальная или реальная машина, которая будет выступать в роли узла для Ansible. Окружение для Vagrant идет в комплекте с этим пособием.
Ansible — это программное решение для удаленного управления конфигурациями. Оно позволяет настраивать удаленные машины. Главное его отличие от других подобных систем в том, что Ansible использует существующую инфраструктуру SSH, в то время как другие (chef, puppet, и пр.) требуют установки специального PKI-окружения.
Пособие покрывает такие темы:
Ansible использует так называемый push mode: конфигурация «проталкивается» (push) с главной машины. Другие CM-системы обычно поступают наоборот – узлы «тянут» (pull) конфигурацию с главной машины.
Этот режим интересен потому что вам не нужно иметь публично доступную главную машину для удаленной настройки узлов; это узлы должны быть доступны (позже мы увидим, что скрытые узлы также могут получать конфигурацию).
console.log(). Собственно говоря, эта команда представляет собой простейший инструмент для отладки программ, который позволяет выводить что-либо в консоль. Однако знание некоторых особенностей этого инструмента позволит тем, кто им пользуется, повысить эффективность работы.
