Пользователь
Для того чтобы успешно проводить расследования инцидентов информационной безопасности необходимо обладать практическими навыками работы с инструментами по извлечению цифровых артефактов. В этой статье будет представлен список полезных ссылок и инструментов для проведения работ по сбору цифровых доказательств.
version: '2'
services:
web:
build: .
ports:
- "80:8000"
depends_on:
- db
entrypoint: "./wait-for-it.sh db:5432"
db:
image: postgres
Jekyll — генератор статических сайтов. Это означает, что на вход ему даётся какая-либо информация, а на выходе получается набор HTML-страничек. Всё отлично когда сайт простой или даже одностраничный. Но что насчёт более сложных сайтов? Справится ли Jekyll? Будет ли удобно?
Данная публикация — попытка обобщить знания, полученные при создании нескольких веб-сайтов. Поэтому оставляю ссылки и на рабочие примеры, и на их полные исходники на GitHub. Уровень материала идёт от простого к сложному.
Я познакомился с Docker довольно давно и, как и большинство его пользователей, был мгновенно очарован его мощью и простотой использования. Простота является основным столпом, на котором основывается Docker, чья сила кроется в легких CLI-командах. Когда я изучал Docker, я захотел выяснить, что происходит у него в бэкграунде, как вообще все происходит, особенно что касается работы с сетью (для меня это одна из самых интересных областей).
Я нашел много разной документации о том, как создавать контейнерные сети и управлять ими, но в отношении того, как именно они работают, материалов намного меньше. Docker широко использует Linux iptables и bridge-интерфейсы для создания контейнерных сетей, и в этой статье я хочу подробно рассмотреть именно этот аспект. Информацию я почерпнул, в основном, из комментариев на github-е, разных презентаций, ну и из моего собственного опыта. В конце статьи можно найти список полезных ресурсов.
Я использовал Docker версии 1.12.3 для примеров в этой статье. Я не ставил своей целью дать исчерпывающее описание Docker-сетей или написать полное введение в эту тему. Я надеюсь, что этот материал будет полезен для пользователей, и я буду рад, если вы в комментариях оставите обратную связь, укажете на ошибки или скажете, чего недостает.
На просторах интернета можно встретить немало статей на тему Infrastructure as Code, утилит SaltStack, Kitchen-CI и так далее, однако, сколько я не встречал различного рода примеров IaC, они зачастую остаются только кодом, как правило, с делением на бранчи в VCS соответствующие наименованию типа среды, например dev/int, возможно даже с тэгами, а говорить о полноценном цикле разработки конфигураций как правило не приходится. Во всяком случае с компаниями, с которыми знаком именно такая ситуация, да и статей не находил.
Может быть оно и понятно — тотальный Agile и "раз-раз и в продакшен".
Попробую исправить ситуацию данной статьей.
В предыдущей статье я рассказал, как Docker использует виртуальные интерфейсы Linux и bridge-интерфейсы, чтобы установить связь между контейнерами по bridge-сетям. В этот раз я расскажу, как Docker использует технологию vxlan, чтобы создавать overlay-сети, которые используются в swarm-кластерах, а также где можно посмотреть и проинспектировать эту конфигурацию. Также я расскажу, как различные типы сетей решают разные задачи связи для контейнеров, которые запущены в swarm-кластерах.
Я предполагаю, что читатели уже знают, как разворачивать swarm-кластеры и запускать сервисы в Docker Swarm. Также в конце статьи я приведу несколько ссылок на полезные ресурсы, с помощью которых можно будет изучить предмет в деталях и вникнуть в контекст обсуждаемых здесь тем. Опять же, буду ждать ваших мнений в комментариях.
Источник изображения
На просторах сети Интернет можно найти немало полезных утилит для Docker. Многие из них принадлежат к разряду Open Source и доступны на Github. В последние два года я достаточно активно использую Docker в большинстве своих проектов по разработке программного обеспечения. Однажды начав работать с Docker, вы осознаете, что он оказывается полезен для гораздо более широкого круга задач, нежели вы изначально предполагали. Вам захочется сделать с Docker еще больше, и он не разочарует!
Docker-сообщество живет активной жизнью, ежедневно производя новые полезные инструменты. За этой бурной деятельностью достаточно сложно уследить. Поэтому я решил выбрать несколько наиболее интересных и полезных из ежедневно используемых мной Docker-утилит. Они делают работу более продуктивной, автоматизируя операции, которые пришлось бы выполнять вручную.
Давайте посмотрим на утилиты, которые помогают мне в процессе докеризации всего и вся.
Немного текста про поддержку IPv6 в докере и ещё кой-какие нюансы docker networking.
Для разминки рассмотрим обычную IPv4-only систему. На хост-машине есть интерфейс eth0. К этому интерфейсу привязан внешний IP-адрес. Ещё есть loopback интерфейс. Когда на такую машину мы устанавливаем docker, он создаёт себе дефолтную сеть с названием bridge. Для этой сети на хост-машине создается еще один интерфейс docker0. У него тоже появляется ip адрес, например, 172.17.0.1. Когда мы запускаем контейнер, докер выделяет контейнеру адрес из выбранной сети (bridge по умолчанию). Например, 172.17.0.5. Внутри контейнера появляется интерфейс eth0 и на нём адрес 172.17.0.5. Итак, с адресами базово разобрались. Теперь попробуем понять, как процесс внутри контейнера может обращаться к внешним ресурсам и как сделать так, чтобы можно было снаружи сходить в контейнер.
Docker замечательно справляется с изолированием приложений и их окружений, облегчая распространение и репликацию состояний между различными средами (dev, test, beta, prod и т. д.). Его использование позволяет избавиться от проблемы «на моей машине все работает» и помогает с легкостью масштабировать приложение по мере его роста.
Docker особенно хорош в том случае, когда у приложения много зависимостей или оно требует использования специфических версий библиотек и инструментов конфигурирования.
В этой статье мы возьмем простое приложение на Rails и подготовим его для использования в Docker-контейнере («докеризуем»).
Средние значения нагрузки (Load averages) — это критически важная для индустрии метрика. Многие компании тратят миллионы долларов, автоматически масштабируя облачные инстансы на основании этой и ряда других метрик. Но на Linux она окутана некой тайной. Отслеживание средней нагрузки на Linux — это задача, работающая в непрерываемом состоянии сна (uninterruptible sleep state). Почему? Я никогда не встречал объяснений. В этой статье я хочу разгадать эту тайну, и создать референс по средним значениям нагрузки для всех, кто пытается их интерпретировать.
Kubernetes — это предназначенный для контейнерной оркестровки фреймворк с открытым исходным кодом. Он был создан с учетом богатейшего опыта Google в области создания сред управления контейнерами и позволяет выполнять контейнеризованные приложения в готовом к промышленной эксплуатации кластере. В механизме Kubernetes много движущихся частей и способов их настройки — это различные системные компоненты, драйверы сетевого транспорта, утилиты командной строки, не говоря уже о приложениях и рабочих нагрузках.
По ходу этой статьи мы установим Kubernetes 1.6 на реальную (не виртуальную) машину под управлением Ubuntu 16.04 примерно за 10 минут. В результате у вас появится возможность начать изучать взаимодействие с Kubernetes посредством его CLI kubectl.
В работе DevOps/Администраторов зачастую возникают моменты, в которые необходимо куда-то кому-то срочно предоставить доступ. Будь то инстанс докера, один из многочисленных контейнеров или какой-то внутренний сервис.
Все знают о возможностях nginx с точки зрения проксирования трафика, балансировки нагрузки между серверами и прочих полезных вещей, помогающих объединять разрозненные сервисы. Однако задача разрешения проблем возникающих в процессе разработки намного обширнее.
Основной посыл данной статьи — показать нестандартный подход к казалось бы простым вещам, таким как предоставление временного доступа внутрь закрытого сегмента.