Прим. перев.: Мы уже не раз писали о containerd и других исполняемых средах для Kubernetes. Новая публикация — перевод недавнего анонса важной вехи в развитии containerd, опубликованного в официальном блоге проекта Kubernetes. Текст написан сотрудниками компаний Google и IBM, которые (конечно, вместе с Docker Inc) вносят значительный вклад в совершенствование containerd.

Ранее в блоге — в заметке Containerd Brings More Container Runtime Options for Kubernetes — мы представляли альфа-версию интеграции containerd с Kubernetes. Очередные 6 месяцев разработки привели к тому, что интеграция стала общедоступной! Это означает, что теперь вы можете использовать containerd 1.1 в качестве исполняемой среды для контейнеров в Kubernetes-кластерах в production.

Containerd 1.1 работает с Kubernetes версии 1.10 и выше, поддерживает все возможности Kubernetes. В инфраструктуре тестов Kubernetes покрытие тестами интеграции с containerd на Google Cloud Platform стало таким же, что и у интеграции с Docker (см. test dashboard).

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

Вместе с большим количеством кода появляется и старая, знакомая проблема: страх изменений. Люди не желают вносить изменения в «чужую» роль, опасаясь испортить её, вместо этого создают собственную копию. Рефакторинг кода не производится, если код прямо сейчас не находится в фокусе разработки, из-за опасения, что внесённые проблемы могут быть обнаружены спустя слишком большое время. Итог: плохой код растёт как снежный ком.

Добрый день/вечер/ночь/утро! Есть один экспериментальный курс по операционным системам. Есть он в Стэнфордском университете. Но часть материалов доступно всем желающим. Помимо слайдов доступны полные описания практических занятий.

Чем этот курс отличается от прочих других? Большая часть кода пишется самостоятельно и выполняется на вполне реальном современном железе. В качестве целевой платформы выбран Raspberry Pi 3 model B. Т.е. достаточно актуальная архитектура AArch64. ARMv8 Cortex-A53, четыре ядра, 64-бита и вот это всё. В качестве основного языка программирования выбран Rust. Который безопасный, быстрый, без GC и так далее. Его, Rust, предполагается изучать во время курса.

Тут есть про диски, файловые системы, операции ввода-вывода, потоки /процессы, планирование, виртуальную память, защиту и безопасность, прерывания, параллелизм и синхронизацию. Как и в любом другом, уважающем себя курсе. Разница в актуальности материала и в количестве практики. Коддить придётся много.

7 ноября на конференции HighLoad++ 2017, в секции «DevOps и эксплуатация» прозвучал доклад «Лучшие практики CI/CD с Kubernetes и GitLab». В нём мы делимся практическим опытом решения проблем, возникающих при построении эффективного процесса CI/CD на базе указанных Open Source-решений.

По традиции рады представить видео с докладом (около часа, гораздо информативнее статьи) и основную выжимку в текстовом виде.

Перевод одной из статей Бена Джонсона из серии "Go Walkthrough" по более углублённому изучению стандартной библиотеки в контексте реальных задач.

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

Пакет io является одним из самых фундаментальных во всей стандартной библиотеке. Он предоставляет набор интерфейсов и вспомогательных функций для работы с потоками байтов.

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

Приветствую Хабр!

4 года назад я публиковал инструкцию по сборке платформы динамического анализа вредоносных файлов Cuckoo Sandbox 1.2. За это время проект успел обрасти внушительным функционалом и огромным комьюнити, недавно обновившись до версии 2.0, которая больше полутора лет висела в стадии Release Candidate.

Я наконец-то подготовил для вас полнейший мануал по сборке Cuckoo Sandbox 2.0.5 со всеми плюшками, какие есть в проекте на данный момент, с упаковкой Cuckoo в venv и без использования root, добавив более 12-ти security утилит в песочницу! По совокупности собранного материала, не побоюсь сказать: "Это самый полный и выверенный шаг в шаг гайд из всех опубликованных в интернете на данный момент". Тем кто, осилит статью до конца — дам маленький совет, что делать, когда песочница собрана и как получить максимальный профит с автоматизации процессов ИБ своими сиилами с помощью опенсорса. Всем гикам, вирусным аналитикам, безопасникам, ребятам из SOC, CERT, CSIRT и просто любителям потыкать кнопки в терминале — добро пожаловать под кат!

В предыдущих статьях о dapp было рассказано про сборку приложений и про запуск в Minikube. При этом dapp запускался локально на машине разработчика. Однако инструмент задумывался для поддержки процессов непрерывной интеграции (CI) и сами мы используем его в основном в связке с GitLab. Чем dapp помогает в процессах CI/CD?

Под капотом сервиса d2c.io мы активно используем Ansible – от создания виртуальных машин в облаках провайдеров и установки необходимого программного обеспечения, до управления Docker-контейнерами с приложениями клиентов.

В первой части мы рассмотрели типы плагинов, которые поддерживает Ansible и сделали несколько своих плагинов: test, filter, action и callback. В этой статье попробуем более сложные модификации.

У этого перевода не совсем обычная история. Системы контроля версий далеки от моих профессиональных интересов. Для рабочих проектов они мне требовались нечасто, причем, разные, так что, каждый раз, когда возникала такая необходимость, я заново вспоминала, как в них делается та или иная операция. А для личных проектов мне хватало возможностей Dropbox, хранящей историю версий файлов.


^{Изображение из твиттера @girlie_mac}

Но вот однажды я на три незабываемых дня попала в роддом — это иногда случается с женщинами. Из развлечений у меня были новорожденная дочь и телефон с большим экраном. Дочь поначалу развлекала плохо (дома она быстро исправилась), а на телефоне помимо книг и фильмов обнаружился текст «Git from the bottom up», который оказался более чем годным… С тех пор прошло почти 3 года, подросшей дочке уже пора самой начинать использовать Git Git стал мейнстримом, если не сказать стандартом в современной разработке, а я с удивлением обнаружила, что перевода на русский этого чуда, полезного не только начинающим, но и продвинутым пользователям Git, до сих пор нет. Исправляю эту ситуацию.

Я помню тот момент, когда подумал «Как же медленно всё работает, что если я распараллелю вызовы?», а спустя 3 дня, взглянув на код, ничего не мог понять в жуткой каше из потоков, синхронизаторов и функций обратного вызова.

Тогда я познакомился с asyncio, и всё изменилось.

Сегодня мы поговорим об очередной интересной технологии — VxLAN — что это за зверь и с чем его едят, да и вообще нужен ли он вам. Мое знакомство с данной технологией началось с изучения гипервизоров — я постоянно натыкался на термин VxLAN, но что это и как работает не знал. В один прекрасный день я решил все-таки прочитать, что это за зверь. Прочитав пару-тройку статей, я усвоил для себя основные аспекты работы технологии и облегченно выдохнул, прочитав, что данная технология — удел гипервизоров и к транспорту имеет косвенное отношение (хотя, как оказалось позже отношение VxLAN к транспорту имеет самое, что ни на есть прямое). После чего про технологию благополучно забыл и вернулся я к ней снова только через год, когда начал погружаться в EVPN — большинство статей и мануалов были именно о симбиозе EVPN и VxLAN. Литературы по данной технологии много, особенно если вы владеете английским. Я же попробую в данной статье рассказать об основах работы данной технологии и показать на практике — как это настраивается и работает. Но начнем с MPLS…

Под капотом d2c.io мы используем Ansible. С его помощью мы создаем виртуальные машины у облачных провайдеров, устанавливаем программное обеспечение, а также управляем Docker-контейнерами с приложениями клиентов.

Ansible – удобный инструмент, который готов к работе почти без настройки. Это возможно благодаря отсутствию агентов (agentless system), поэтому не нужно ничего предустанавливать на обслуживаемые хосты.

Для подключения к хостам в большинстве случаев используется ssh. Однако оборотной стороной этой медали является определенная медлительность, так как вся логика находится на управляющем сервере и каждую задачу (task) Ansible формирует локально и отправляет на исполнение через SSH-подключение. Затем он принимает результат, анализирует его и переходит к следующему шагу. В статье мы рассмотрим, как можно ускорить работу Ansible.

Прим. перев.: Этот материал, озаглавленный в оригинале как «What happens when… Kubernetes edition!» и написанный Jamie Hannaford из компании Rackspace, является отличной иллюстрацией работы многих механизмов Kubernetes, которые зачастую скрыты от нашего глаза, но весьма полезны для лучшего понимания устройства этой Open Source-системы, алгоритма работы и взаимосвязей её компонентов. Поскольку вся статья весьма объёмна, её перевод разбит на две части. В первой речь идёт про работу kubectl, kube-apiserver, etcd и initializers.

P.S. Некоторые оригинальные ссылки на код в master-ветках были заменены на последние к моменту перевода коммиты, чтобы актуальность номеров строк, к которым отсылает автор, сохранялась долгое время.



Представим, что я хочу задеплоить nginx в кластере Kubernetes. Я введу в терминале нечто такое:

kubectl run --image=nginx --replicas=3

… и нажму на Enter. Через несколько секунд увижу 3 пода с nginx, распределённые по всем рабочим узлам. Работает — словно по волшебству, и это здорово! Но что на самом деле происходит под капотом?

Привет, Хабр!

В этой статье хочется поделится с вами настройкой девелоперского окружения под разработку скриптов на Python и запуск их в изолированном окружении, практически за пару кликов в редакторе VS Code.

В качестве изолированного окружения будет рассмотрена первичная настройка и создание контейнера на базе LXC под управлением ОС Ubuntu 17.10. Почему не Docker? Сложно ответить, выдать какие-то аргументы. От части концепция виртуализации ОС субъективно ближе по духу, чем виртуализация процессов, но принцип который здесь будет изложен, с некоторыми поправками, подойдет к запуску кода в Docker-контейнерах.

Что вы получите?

• Научитесь запускать в один клик python-скрипты в контейнере, а также удаленный debug из VS Code
• Узнаете как установить LXD, настроить сеть и запустить первый контейнер
• Ознакомитесь с установкой и настройкой редактора исходного кода VS Code, набором расширений которые позволят комфортно писать и отлаживать код.

Чего здесь не будет?

• Не будет полного обзора LXC/LXD, вам придется самостоятельно найти дополнительную информацию о Linux-контейнерах.
• Не будет рассмотрен python модуль virtualenv для создания виртуального окружения на хосте разработчика как альтернатива контейнерам.
• Не будет сравнения в духе Docker vs LXD, выводы вы сделаете самостоятельно на основании вашего опыта.

Итак, у вас есть кластер Kubernetes, а для проброса внешнего трафика сервисам внутри кластера вы уже настроили Ingress-контроллер NGINX, ну, или пока только собираетесь это сделать. Класс!

Я тоже через это прошел, и поначалу все выглядело очень просто: установленный NGINX Ingress-контроллер был на расстоянии одного helm install. А затем оставалось лишь подвязать DNS к балансировщику нагрузки и создать необходимые Ingress-ресурсы.

Спустя несколько месяцев весь внешний трафик для всех окружений (dev, staging, production) направлялся через Ingress-серверы. И все было хорошо. А потом стало плохо.

Все мы отлично знаем, как это бывает: сначала вы заинтересовываетесь этой новой замечательной штукой, начинаете ей пользоваться, а затем начинаются неприятности.

Многие DevOps-инженеры и системные администраторы, особенно успевшие поработать с Kubernetes, уже слышали про проект CRI-O, озаглавленный как «легковесная исполняемая среда для контейнеров в Kubernetes». Однако зачастую представления о его назначении, возможностях и статусе весьма размыты — из-за молодости проекта, отсутствия опыта практического применения и растущего числа изменений в области стандартов для контейнеров. Эта статья — ликбез о CRI-O, рассказывающая о появлении проекта, его особенностях и актуальном статусе.

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

• обеспечивать отказоустойчивость и избыточность;
• легко масштабироваться;
• просто и быстро решать задачу добавления и блокировки пользователей VPN;
• балансировать нагрузку между входными нодами;
• одинаково хорошо работать для клиентов на GNU/Linux, Mac OS X и Windows;
• поддерживать клиентов, которые находятся за NAT.

Готовых решений, удовлетворяющих всем поставленным условиям, не нашлось. Поэтому мы собрали его на базе популярных Open Source-продуктов, а теперь с удовольствием делимся полученным результатом в этой статье.

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

Однако сеть linkmeup выросла до размеров федерального оператора. Возможность управления трафиком и быстрого восстановления сервисов стали очень важным требованием в MPLS-сети.
Пора внедрять Traffic Engineering.

---

Зачем вообще может понадобиться инжиниринг трафика?

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

Содержание:

1. FreeIPA агенте в lxc контейнерах
2. Библиотека для использования API в python
3. Несколько слов про Ansible модули
4. FreeIPA агент в debian
5. Реплика в Амазоне

Данная статья написана так сказать по заявкам слушателей нашей радиостанции. При настройке Option C на JunOS у многих возникает один и тот же вопрос: почему ничего не работает хотя все вроде бы правильно? На JunOS все не так тривиально, как на Cisco и проблем может быть несколько. Перейдем непосредственно к сути: симптомы такие — вы настроили на ASBR BGP-LU сессию для организации Opt.C стыка на оборудовании Juniper (и естественно VPNv4 сессию между рефлекторами, но она тут не причем), но пинги между лупбеками PE маршрутизаторов различных автономных систем есть, а вот L3VPN не работает. Давайте разбираться, почему это происходит и как с этим бороться.