Статьи

Ранее мы уже писали о конфигурировании VXLAN в Linux. Представляем перевод еще одной англоязычной статьи “VXLAN: BGP EVPN with Cumulus Quagga (or FRR)” автора Vincent Bernat, которая может быть интересна разработчикам или администраторам, ищущим решение для реализации VXLAN в больших сетях, где недоступно мультивещание.

Недавно мы писали о выпуске первого релиза расширения для CloudStack, позволяющего выделять дополнительные частные сети, организуемые посредством оверлейных сетей VXLAN. При разработке расширения нам очень помог блог Vincent Bernat из Exoscale. Сегодня мы подробнее остановимся на конфигурировании VXLAN в Linux.

Данная статья является адаптированным и дополненным переводом англоязычной статьи автора Vincent Bernat. В статье вы встретите ссылки и на другие статьи автора.

VXLAN (Virtual eXtensible Local Area Network) – оверлейная сеть для передачи трафика Ethernet по существующей (высокодоступной и масштабируемой) IP-сети при одновременном размещении большого числа групп пользователей. Данное определение представлено в RFC 7348. VXLAN вполне реализованы в Linux, начиная с версии 3.12 поддерживаются мультивещание (multicast) и одноадресная передача (unicast), а также IPv6 и IPv4. Традиционно VXLAN работают с использованием групп мультивещания, но не всегда они применимы. В этой статье мы рассмотрим различные методы настройки сети VXLAN в Linux, и более подробно остановимся на вариантах применения одноадресной передачи (unicast).

GitLab CI предоставляет удобную возможность сохранения артефактов сборок в GitLab. Артефакт - любой файл, который разработчик хочет сохранить на продолжительное время после сборки. Данная возможность может использоваться для хранения дистрибутивов и различных журналов сборок. Использовать артефакты очень просто. В статье разберем как это реализовано на примере публикации собранного DEB пакета, который позже возможно скачать из GitLab.

Артефакты GitLab CI не всегда являются самым удобным средством, иногда вам может потребоваться подключить FTP, SFTP, публикацию в Nexus или другие системы хранения артефактов, однако, часто достаточно просто иметь хранилище, которое позволит просто получить доступ к результату сборки.

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

Публикация кода в открытые репозитории Git. Допустим, вы разрабатываете продукт и какие-то его ветки должны быть доступны для сообщества или вы, в принципе, разрабатываете продукт с открытым кодом, но ведете разработку в GitLab, выполняете тестирование и доставку с помощью GitLab CI. Обычно вы хотите, чтобы пользователи имели возможность постоянного доступа к исходному коду продукта, поэтому хотите выкладывать его на GitHub или BitBucket.

Публикация кода в репозиторий клиента. Вы разрабатываете программный продукт для одного или более клиентов, а при создании релизов публикуете исходный код на их внутренние GitLab серверы, на которых для релизного кода отрабатывают соответствующие процедуры CI/CD и выполняется развертывание кода в продуктовую или ‘staging’ среду. При этом, вы можете хотеть публиковать разным клиентам разные ветки репозитория, которые содержат специализированные модификации.

Ранее мы уже писали о DC/OS – унифицированной распределённой платформе для оркестрации приложений. Она позволяет за минуты развернуть из каталога готовых решений (DC/OS Universe) такие системы как Apache Spark, Apache Kafka, Apache Cassandra, HDFS, Elasticsearch, NGINX, OpenVPN и другие. Ключевым элементом системы является кластерный менеджер Mesos. В качестве фреймворка для оркестрации поставляется Marathon. После того, как система стала доступной как open-source, интерес к ней значительно возрос.