• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Надёжное ПО повышает доверие пользователей к организации, эффективность процессов разработки и качество продуктов. Сбои вредят клиентам и бизнесу, но при разработке новых функций многие организации думают только об устранении последствий инцидентов и решают проблемы тактически, а не стратегически. Часто они не понимают, что можно работать быстро и при этом создавать надёжный продукт.

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

Не существует набора строгих правил, следуя которым можно гарантировать надёжность продукта. В этой статье SRE-инженеры из Google расскажут о том, как оценить культуру надёжности в вашей организации и какой она должна быть.

Содержание

• cat
• head
• tail
• wc
• grep
• cut
• paste
• sort
• uniq
• awk
• tr
• fold
• sed
• Реальные примеры
• Углубляемся: циклы for и xargs
• Итоги
• Что дальше

Развёртывание в Kubernetes из GitLab

Это продолжение предыдущего туториала про командную разработку с использованием GitLab. Фокус предыдущей статьи был на организации непрерывной поставки в работе команды. В этой статье мы уделим основное внимание именно практическим действиям необходимым для развёртывания из GitLab в Kubernetes.

А именно мы возьмём максимально простое но достаточно содержательное приложение на React.js, докеризуем его, затем развернём в Kubernetes локально при помощи Docker Desktop. После этого развернём его уже на Google Cloud Platform (GCP), и завершим разработкой CI/CD конвейера в GitLab для публикации нашего приложения в Google Kubernetes Engine.

Желательны но необязательны базовые знания

• Docker;
• Kubernetes;
• Git;
• Node.js;
• React;
• Bash.

В дальнейшем мы сделаем следующее.

• ? Познакомимся c нашим приложением, обсудим из чего оно состоит.
• ? Докеризуем наше приложение.
• ☸️ Развернём наше приложение в Kubernetes локально на Docker Desktop.
• ☁️ Обсудим особенности GCP и как нужно изменить наше приложение, а затем ещё раз развернём наше приложение в Kubernetes но уже в GCP.
• ? Завершим наш туториал созданием конвейера для развертывания приложения в GCP при помощи GitLab.

Протокол SSH v.2 является важной составляющей безопасных компьютерных сетей. Он криптографически надёжен, быстр, универсален и широко распространён. Многие крупные облачные провайдеры даже не пытаются заменить его каким-либо альтернативным, собственным решением, что подчёркивает его силу. 

В этой статье я хочу продемонстрировать некоторые интересные и универсальные возможности протокола SSH и его реализации OpenSSH. 

Рекомендации, рассмотренные в этой статье, помогут вам реализовать мониторинг на базе Prometheus и улучшить вашу производительность.

Prometheus — одна из базовых составляющих cloud-native-архитектуры. Он уже стал стандартом де-факто для мониторинга Kubernetes. Однако многие сторонние и облачные приложения изначально не предоставляют метрик в формате Prometheus. Например, Linux не предоставляет таких метрик. Для этого и предназначены экспортеры, такие как node exporter. Его легко скачать, запустить и получить сотни метрик для операционной системы.

Secure DevOps, также известный как DevSecOps, обеспечивает безопасность и мониторинг на протяжении всего жизненного цикла приложения: от разработки до продакшена. Что позволяет создавать безопасные, стабильные и высокопроизводительные приложения. Этот подход встраивается в ваш процесс разработки и предоставляет единый источник правды для DevOps-команд, разработчиков и служб безопасности, чтобы максимально повысить эффективность и обеспечить прозрачность при устранении неисправностей и оптимизации.

В предыдущей статье мы рассмотрели вопросы хранения учетных данных в ОС семейства Линукс. Теперь перейдем к обсуждению вопросов правильной и не очень настройки прав доступа к различным объектам операционной системы.

Напомню основные моменты относительно учетных записей в Линукс: есть суперпользователь root (id=0), который может все и есть все остальные учетные записи (id от 500 или 1000), которые имеют ряд ограничений и по идее не могут нанести большого вреда системе.

Но на практике возможны различные ситуации, когда обычному пользователю необходимы административные права. Например, обычный пользователь не может прочитать файл с хэшами паролей /etc/shadow, но он может изменить свой собственный пароль с помощью команды passwd. Очевидно, что для внесения изменений в защищенный файл команда должна выполняться с правами суперпользователя. И таких примеров может быть довольно много.

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

Всем привет.

Хочу поделиться своим опытом успешной сдачи экзамена Certified Kubernetes Security (CKS) от Linux Foundation. Данный экзамен, как нетрудно догадаться, проверяет наши способности настраивать различные аспекты безопасности кластера Kubernetes и приложений, работающих в нем. Экзамен мне понравился, он рассматривает безопасность с различных точек зрения, а также использует очень полезные внешние инструменты, такие как Falco, Trivy, kube-bench, Open Policy Agent, gVisor и др. Сам экзамен мне показался умеренно сложным, в отличие от CKA, который больше ориентирован на новичков в Kubernetes.

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

На текущий момент существует всего два экзамена по безопасности Kubernetes - это, собственно, сам CKS, а также Red Hat Certified Specialist in Security: Containers and OpenShift, имеющий дело с безопасностью OpenShift. Эти два экзамена во многом пересекаются, однако по Опеншифту я считаю экзамен все же сложнее (его я благополучно завалил).

Экзамен отдельно стоит стоит 300$, официальный курс Kubernetes Security Fundamentals (LFS260) стоит 299$, можно купить курс и экзамен вместе за 499$. Я купил курс и экзамен вместе за 200$ на традиционной предновогодней распродаже от Linux Foundation.

Необходимым условием для сдачи CKS является наличие действующего сертификата CKA (Certified Kubernetes Administrator). Вы можете купить CKS, но не сможете назначить экзамен, пока не получите CKA. Звучит логично, поскольку экзамен CKS является гораздо более сложным чем CKA.

Но ближе к делу. Для подготовки я использовал два курса:

Разберём как при помощи VictoriaMetrics замониторить kubernetes. Откуда собирать метрики и как автоматически обнаруживать новые цели. Черная магия релейблинга и как она работает. Аннотации для мониторинга приложений и что делать когда их гибкости не хватает

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

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

Мне нужен был гайд, который сочетает эти две вещи: сначала «почему так принято», а затем — «как правильно делать». В результате такой гайд мне пришлось написать самому. Его цель — объяснить разработчикам с любым бэкграундом, что такое метрики, как правильно о них думать и осмысленно использовать. Сначала гайд жил во внутренней документации Точки, но я решил сделать его публичным — возможно, кому-то этот опыт будет полезен. Разбираться будем с Prometheus и Grafana. Если у вас другой стек — не страшно. Мы затронем и фундаментальные темы: например, перцентили, производные и кардинальность.

Гайд будет выходить как цикл статей. Сначала посмотрим на архитектуру: как собираются метрики и где хранятся. Дальше разберемся с типами метрик — они не так просты, как кажется. Потом придется немного отвлечься на математику (но только с инженерной точки зрения!). И, наконец, научимся писать запросы, но не просто так: сразу посмотрим на разные грабли и неочевидные моменты.

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

Под катом: формат данных, способы отправки, типы метрик и их применение, кардинальность.

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

Поскольку Prometheus хранит данные в виде временных рядов (time-series data model), запросы PromQL радикально отличаются от привычного SQL. Понимание, как работать с данными в Prometheus, является ключом к тому, чтобы научиться писать эффективные запросы.

Приветствую всех любителей Infrastructure as Code.

Как я уже писал в предыдущей статье, я люблю заниматься автоматизацией инфраструктуры. Сегодня представляю вашему вниманию вариант построения GitOps для реализации подхода Monitoring as Code.

Привет, Хабр!
Меня зовут Радик, Head of DevOps of AGIMA!

В этой статье я постарался показать, как можно использовать Prometheus в качестве системы мониторинга для микросервисной архитектуры. Подробно рассмотрел архитектуру Prometheus и взаимодействие его компонентов. Обозначил ключевые характеристики благодаря чему эта система получила такое широкое распространение в средах использующих контейнеризацию. Предупреждаю сразу: статья получилась довольно объемной. Эта статься будет полезна для начинающих DevOps специалистов, которые планируют или уже используют в своей работе Docker, Kubernetes. Итак, начнем!

За последние пару лет мне довольно часто приходилось сталкиваться с Kubernetes, однако обычно это всегда происходило с позиции разработчика. Посмотреть список подов, их статусы, логи и т.п. В общем, ничего сложного.

Недавно я решил заняться изучением Kubernetes чуть глубже, чтобы лучше понимать, как он работает и что умет. Но тут возникла очевидная проблема: нужна какая-то песочница, в которой можно было бы экспериментировать, не боясь при этом что-то сломать, а ещё лучше иметь возможность в любой момент откатиться назад.

Обычно изучение Kubernetes стоит начинать с minikube - консольной утилиты, которая умеет быстро создавать кластер из одного узла с использованием VirtualBox. Это самый лучший вариант для быстрого старта.

Но есть и другой вариант. Можно взять VirtualBox, создать несколько виртуальных машин, например, с Ubuntu Server и настроить небольшой кластер Kubernetes прямо на своём домашнем компьютере.

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

Здесь я решил собрать всё вместе и описать процесс настройки небольшого кластера Kubernetes с использованием VirtualBox настолько подробно, насколько мне самому хотелось бы его видеть. Надеюсь, что эта информация сможет помочь другим разработчикам в их экспериментах.

Осторожно, трафик! В статье очень много скриншотов.

Что такое Linux?

1. Linux Kernel aka Ядро
2. GNU Core Utilities (coreutils)
3. Bash — интерпретатор командной строки
4. Системы управления пакетами и пакетные менеджеры
5. Init systems — системы инициализации
6. systemd
7. Ваш первый вход на сервер
8. Управляем пользователями
9. Сети
10. FHS — Filesystem Hierarchy Standard — навигация в файловых системах Linux
11. Window system / display server — сервер экранов
12. Полезные ссылки и список литературы для изучения