Интересные проекты сокращатель ссылок для запуска на Docker


Оглавление (нажмите, чтобы открыть):

Шпаргалка Docker

22 October 2014

Создание образа

docker pull ОБРАЗ — загружает образ из Docker Hub (аналог GitHub для Docker)

docker build ПУТЬ | URL — создает образ с помощью Dockerfile
Параметры:

  • -t | —tag=»» — помечает созданный образ переданным названием (и, тэгом, если он будет передан)
  • —rm — Удаляет промежуточные контейнеры после успешной сборки (по умолчанию == true)

Управление образами

docker rmi — Удаляет образ, образ не может быть удален, если существуют контейнеры (даже незапущенные), которые основаны
на данном образе
Параметры:

  • -f — позволяет удалить образ даже если на нём основаны контейнеры

docker images — Отображает список всех существующих образов
Параметры:

  • -a | —all — отображает все образы (по умолчанию не отображает промежуточные контейнеры)
  • -q — отображает только id образов, вместо таблицы

Запуск и остановка контейнеров

docker run ОБРАЗ [КОМАНДА + АРГУМЕНТЫ] — Запускает выбранный образ в новом контейнере
Параметры:

  • -d | —detach — запускает контейнер в фоновом режиме и выводит только >false )
  • -i | —interactive — запускает контейнер в интерактивном режиме (оставляет STDIN открытым, даже если контейнер запущен в неприкрепленном режиме)
  • -t | —tty — запускает псевдотерминал, часто используется с -i
  • -p | —publish=[] — пробрасывает порты контейнера в хост. Формат: ip:hostPort:containerPort | ip::containerPort | hostPort:containerPort | containerPort
  • -e | —env=[] — пробрасывает переменные окружения внутрь контейнера.
  • -v | —volume=[] — пробрасывает директорию файловой системы внутрь контейнера

docker stop КОНТЕЙНЕР — останавливает контейнер, передавая внутрь SIGTERM, а по истечении таймаута — SIGKILL

  • docker start КОНТЕЙНЕР — запускает остановленный контейнер.
    Параметры:
    • -i | —interactive — аналогично docker run -i
  • docker restart КОНТЕЙНЕР — Перезапускает выбранный контейнер с помощью docker stop и docker start
  • docker kill КОНТЕЙНЕР — Убивает контейнер, передавая внутрь SIGKILL
  • Управление контейнерами

    • docker port КОНТЕЙНЕР — отображает маппинг портов между хостом и контейнером
    • docker ps — отображает список запущенных контейнеров
      Параметры:
      • -a | —all=(true|false) — отображать ли все контейнеры. По умолчанию == false , т.е. отображаются только запущенные контейнеры
      • -q — отображает только ID контейнеров вместо таблицы
    • docker rm КОНТЕЙНЕР — удаляет контейнер. По умолчанию можно удалить только запущенный контейнер.
      Параметры:
      • -f | —force=(true|false) — позволяет удалить запущенный контейнер. Используется передача SIGKILL внутрь.
    • docker diff — отображает изменения относительно образа.

    Синтаксис Dockerfile

    Dockerfile служит скриптом сборки для команды docker build . Перед началом сборки docker передает сборщику всё содержимое папки с Dockerfile’ом,
    поэтому располагать его в корневой директории системы будет не лучшей идеей.

    Первая инструкция обязательно должна быть инструкцией FROM.

    FROM ОБРАЗ | FROM ОБРАЗ:ТЭГ — Задает базовый образ для последующих инструкций. Может встречаться несколько раз в одном Dockerfile,
    если необходимо собрать несколько образов за раз.

    MAINTAINER имя — Позволяет задать поле Author сгенерированного образа

    RUN команда | RUN [«исполняемый файл», «параметр1», «параметр2», ..] — Запускает команду на основе текущего образа и фиксирует изменения в новом образе. Новый образ будет использован для исполнения последующих инструкций. Первый синтаксис подразумевает запуск команд в стандартной оболочке (bin\sh -c)

    CMD [«исполняемый файл», «параметр1», «параметр2»] | CMD [«параметр1», «параметр2»] | CMD команда параметр1 параметр2 — Предоставляет значения по умолчанию для запуска контейнера. Эти значения могут как включать исполняемый файл (варианты 1, 3), так и не включать его (вариант 2). В последнем случае запускаемая команда
    должна быть задана с помощью инструкции ENTRYPOINT .

    EXPOSE порт — Информирует Docker, что контейнер будет прослушивать указанные порты во время исполнения. Docker может использовать эту информацию, чтобы соединять контейнеры между собой используя связи. EXPOSE сам по себе не делает порт доступным из хостовой системы. Для того, чтобы открыть порты в хостовую систему следует использовать флаг -p .

    ENV ключ значение — Позволяет задавать переменные окружения. Эти переменные будут использованы при запуске контейнера из собранного образа. Могут быть просмотрены с помощью команды docker inspect , а также переопределены с помощью флага —env команды docker run .

    ADD ОТКУДА КУДА — Используется для добавления новых файлов, директорий или ссылок на удалённые файлы в файловую систему контейнера. Несколько ОТКУДА может быть передано одновременно, но в этом случае все адреса должны быть относительны для директории, из которой происходит сборка. Каждый вхождение ОТКУДА может содержатьодин или несколько символов подстановки, которые будут разрешены с использование функции языка Go filepath.Match. КУДА должен быть абсолютным путем внутри контейнера.

    ENTRYPOINT [«исполняемый файл», «параметр1», «параметр2»] | ENTRYPOINT команда параметр1 параметр2 — позволяет сконфигурировать контейнер так, чтобы он запускался как исполняемый файл. В отличии от команды CMD значение не будет переопределено аргументами, переданными в команду docker run . Таким образом, аргументы из команды docker run будут переданы внутрь контейнера, т.е. docker run ОБРАЗ -d передаст -d исполняемому файлу.

    VOLUME [ПУТЬ] — создает точку монтирования с указанным именем и помечает её как содержащую подмонтированные разделы из хостовой системы или других контейнеров. Значение может быть задано как массив JSON, например, VOLUME [«/var/log/»] , так и как обычной строкой с одним или несколькими аргументами, например VOLUME /var/log или VOLUME /var/log /var/db

    USER имя — позволяет задавать имя пользователя или UID, который будет использован для запуска образа, а так же для любой из инструкций RUN

    WORKDIR ПУТЬ — задает рабочую директорию для команд RUN , CMD и ENTRYPOINT . Инструкция может быть использована несколько раз. Если ПУТЬ относителен, то он будет относительным для ПУТИ, заданным предыдущей инструкцией WORKDIR .

    Как и для чего использовать Docker

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

    Содержание

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

    (В статье намеренно опущены многие детали, чтобы не грузить информацией, которая не нужна для ознакомления).

    Установка

    Докер поставляется в виде Community Edition (CE) и Enterprise Edition (EE). Нас интересует CE. На главной странице этой версии доступны ссылки для скачивания под все популярные платформы. Выберите вашу и установите Докер.

    В работе Докера есть одна деталь, которую важно знать при установке на Mac и Linux. По умолчанию Докер работает через unix сокет. В целях безопасности сокет закрыт для пользователей, не входящих в группу docker. И хотя установщик добавляет текущего пользователя в эту группу автоматически, Докер сразу не заработает. Дело в том, что если пользователь меняет группу сам себе, то ничего не изменится до тех пор, пока пользователь не перелогинится. Такова особенность работы ядра. Для проверки того, в какие группы входит ваш пользователь, можно набрать команду id .

    Проверить успешность установки можно командой docker info :

    Она выдает довольно много информации о конфигурации самого Докера и статистику работы.

    Запуск

    На этом этапе команды на выполнение даются “как есть” без объяснения деталей. Подробнее о том, как их формировать и что в них входит разбирается позже.

    Начнем с самого простого варианта:

    При первом вызове данная команда начнет скачивать образ (image) nginx, поэтому придется немного подождать. После того, как образ скачается, запустится bash, и вы окажетесь внутри контейнера (container).

    Побродите по файловой системе, посмотрите папку /etc/nginx . Как видите, её содержимое не совпадает с тем, что находится у вас на компьютере. Эта файловая система появилась из образа nginx. Все, что вы сделаете здесь внутри, никак не затронет вашу основную файловую систему. Вернуться в родные скрепы можно командой exit .

    Теперь посмотрим вариант вызова команды cat , выполненной уже в другом контейнере, но тоже запущенном из образа nginx:

    Команда выполняется практически мгновенно, так как образ уже загружен. В отличие от предыдущего старта, где запускается баш и начинается интерактивная сессия внутри контейнера, запуск команды cat /etc/nginx/nginx.conf для образа nginx выведет на экран содержимое указанного файла (взяв его из файловой системы запущенного контейнера) и вернет управление в то место, где вы были. Вы не окажетесь внутри контейнера.

    Последний вариант запуска будет таким:

    Данная команда не возвращает управление, потому что стартует nginx. Откройте браузер и наберите localhost:8080 . Вы увидите как загрузилась страница Welcome to nginx!. Если в этот момент снова посмотреть в консоль, где был запущен контейнер, то можно увидеть, что туда выводится лог запросов к localhost:8080 . Остановить nginx можно командой Ctrl + C .

    Несмотря на то, что все запуски выполнялись по-разному и приводили к разным результатам, общая схема их работы — одна. Докер при необходимости автоматически скачивает образ (первый аргумент после docker run ) и на основе него стартует контейнер с указанной командой.

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

    Контейнер — запущенный процесс операционной системы в изолированном окружении с подключенной файловой системой из образа.

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

    Попробуйте выполнить команду docker run -it ubuntu bash и наберите ps auxf внутри запущенного контейнера. Вывод будет таким:

    Как видно, процесса всего два, и у Bash P >/home командой ls /home и убедиться, что она пустая. Также обратите внимание, что внутри контейнера по умолчанию используется пользователь root .

    Зачем все это?

    Докер — универсальный способ доставки приложений на машины (локальный компьютер или удаленные сервера) и их запуск в изолированном окружении.

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

    • Установить все необходимые зависимости под вашу операционную систему (их список еще надо найти).
    • Скачать архив, распаковать.
    • Запустить конфигурирование make configure .
    • Запустить компиляцию make compile .
    • Установить make install .

    Как видите, процесс нетривиальный и далеко не всегда быстрый. Иногда даже невыполнимый из-за непонятных ошибок. И это не говоря про загрязнение операционной системы.


    Докер позволяет упростить эту процедуру до запуска одной команды причем с почти 100% гарантией успеха. Посмотрите на вымышленный пример, в котором происходит установка программы Tunnel на локальный компьютер в папку /usr/local/bin используя образ tunnel:

    Запуск этой команды приводит к тому, что в основной системе в папке /usr/local/bin оказывается исполняемый файл программы, находящейся внутри образа tunnel. Команда docker run запускает контейнер из образа tunnel, внутри происходит компиляция программы и, в конечном итоге, она оказывается в папке /usr/local/bin основной файловой системы. Теперь можно стартовать программу, просто набрав tunnel в терминале.

    А что если программа, которую мы устанавливаем таким способом, имеет зависимости? Весь фокус в том, что образ, из которого был запущен контейнер, полностью укомплектован. Внутри него установлены все необходимые зависимости и его запуск практически гарантирует 100% работоспособность независимо от состояния основной ОС.

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

    Старый способ использования Jekyll требовал установки на вашу основную систему как минимум Ruby и самого Jekyll в виде гема (gem — название пакетов в Ruby). Причем, как и всегда в подобных вещах, Jekyll работает только с определенными версиями Ruby, что вносит свои проблемы при настройке.

    С Докером запуск Jekyll сводится к одной команде, выполняемой в папке с блогом (подробнее можно посмотреть в репозитории наших гайдов):

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

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

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

    Но в какой-то момент все изменилось. Картинка стоит тысячи слов:

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

    То же самое произошло и в разработке ПО. Docker стал универсальным средством доставки софта независимо от его структуры, зависимостей и способа установки. Все, что нужно программам, распространяемым через Докер, находится внутри образа и не пересекается с основной системой и другими контейнерами. Важность этого факта невозможно переоценить. Теперь обновление версий программ никак не задействует ни саму систему, ни другие программы. Сломаться больше ничего не может. Все, что нужно сделать, это скачать новый образ той программы, которую требуется обновить. Другими словами, Докер убрал проблему dependency hell и сделал инфраструктуру immutable (неизменяемой).

    Больше всего Docker повлиял именно на серверную инфраструктуру. До эры Докера управление серверами было очень болезненным мероприятием даже не смотря на наличие программ по управлению конфигурацией (chef, puppet, ansible). Основная причина всех проблем — изменяемое состояние. Программы ставятся, обновляются, удаляются. Происходит это в разное время на разных серверах и немного по разному. Например, обновить версию таких языков, как PHP, Ruby или Python могло стать целым приключением с потерей работоспособности. Проще поставить рядом новый сервер и переключиться на него. Идейно Докер позволяет сделать именно такое переключение. Забыть про старое и поставить новое, ведь каждый запущенный контейнер живет в своем окружении. Причем, откат в такой системе тривиален: все что нужно — остановить новый контейнер и поднять старый, на базе предыдущего образа.

    Приложение в контейнере

    Теперь поговорим о том, как приложение отображается на контейнеры. Возможны два подхода:

    1. Все приложение — один контейнер, внутри которого поднимается дерево процессов: приложение, веб сервер, база данных и все в этом духе.
    2. Каждый запущенный контейнер — атомарный сервис. Другими словами каждый контейнер представляет из себя ровно одну программу, будь-то веб-сервер или приложение.

    На практике все преимущества Docker достигаются только со вторым подходом. Во-первых, сервисы, как правило, разнесены по разным машинам и нередко перемещаются по ним (например, в случае выхода из строя сервера), во-вторых, обновление одного сервиса, не должно приводить к остановке остальных.

    Первый подход крайне редко, но бывает нужен. Например, Хекслет работает в двух режимах. Сам сайт с его сервисами использует вторую модель, когда каждый сервис отдельно, но вот практика, выполняемая в браузере, стартует по принципу один пользователь — один контейнер. Внутри контейнера может оказаться все, что угодно в зависимости от практики. Как минимум, там всегда стартует сама среда Хекслет IDE, а она в свою очередь порождает терминалы (процессы). В курсе по базам данных в этом же контейнере стартует и база данных, в курсе, связанном с вебом, стартует веб-сервер. Такой подход позволяет создать иллюзию работы на настоящей машине и резко снижает сложность в поддержке упражнений. Повторюсь, что такой вариант использования очень специфичен и вам вряд ли понадобится.

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

    Работа с образами

    Docker — больше, чем просто программа. Это целая экосистема со множеством проектов и сервисов. Главный сервис, с которым вам придется иметь дело — Registry. Хранилище образов.

    Концептуально оно работает так же, как и репозиторий пакетов любого пакетного менеджера. Посмотреть его содержимое можно на сайте https://store.docker.com/ (либо по старому адресу https://hub.docker.com/), кликнув по ссылке Containers.

    Когда мы выполняем команду run docker run , то Docker проверяет наличие указанного образа на локальной машине и скачивает его по необходимости. Список образов, уже скачанных на компьютер, можно посмотреть командой docker images :

    Разберемся с тем, как формируется имя образа, и что оно в себя включает.

    Вторая колонка в выводе выше называется TAG. Когда мы выполняли команду docker run nginx , то на самом деле выполнялась команда docker run nginx:latest . То есть мы не просто скачиваем образ nginx, а скачиваем его конкретную версию. Latest — тег по умолчанию. Несложно догадаться что он означает последнюю версию образа.

    Важно понимать что это всего лишь соглашение, а не правило. Конкретный образ вообще может не иметь тега latest, либо иметь, но он не будет содержать последние изменения, просто потому что никто их не публикует. Впрочем, популярные образы следуют соглашению. Как понятно из контекста, теги в Докере изменяемы, другими словами, вам никто не гарантирует, что скачав образ с одним и тем же тегом на разных компьютерах в разное время вы получите одно и тоже. Такой подход может показаться странным и ненадежным, ведь нет гарантий, но на практике есть определенные соглашения, которым следуют все популярные образы. Тег latest действительно всегда содержит последнюю версию и постоянно обновляется, но кроме этого тега активно используется семантическое версионирование. Рассмотрим https://store.docker.com/images/nginx

    Теги, в которых присутствует полная семантическая версия (x.x.x) всегда неизменяемы, даже если в них встречается что то еще, например 1.12.2-alphine. Такую версию смело нужно брать для продакшен-окружения. Теги, подобные такому 1.12, обновляются при изменении path версии. То есть внутри образа может оказаться и версия 1.12.2 и в будущем 1.12.8. Точно такая же схема и с версиями, в которых указана только мажорная версия, например 1. Только в данном случае обновление идет не только по патчу, но и по минорной версии.

    Как вы помните, команда docker run скачивает образ если его нет локально, но эта проверка не связана с обновлением содержимого. Другими словами, если nginx:latest обновился, то docker run его не будет скачивать, он использует тот latest, который прямо сейчас уже загружен. Для гарантированного обновления образа существует другая команда: docker pull . Вот она всегда проверяет обновился ли образ для определенного тега.

    Кроме тегов имя образа может содержать префикс: например, etsy/chef . Этот префикс является именем аккаунта на сайте, через который создаются образы, попадающие в Registry. Большинство образов как раз такие, с префиксом. И есть небольшой набор, буквально сотня образов, которые не имеют префикса. Их особенность в том, что эти образы поддерживает сам Docker. Поэтому если вы видите, что в имени образа нет префикса, значит это официальный образ. Список таких образов можно увидеть здесь: https://github.com/docker-library/official-images/tree/master/library

    Удаляются образы командой docker rmi .

    Если в Докере присутствует хоть один контейнер из удаляемого образа, то Докер не даст его удалить по понятным причинам. Если вы все же хотите удалить и образ и все контейнеры связанные с ним, то используйте флаг -f .

    Управление контейнерами

    Картинка описывает жизненный цикл (конечный автомат) контейнера. Кружками на нем изображены состояния, жирным выделены консольные команды, а квадратиками показывается то, что в реальности выполняется.

    Проследите путь команды docker run . Несмотря на то, что команда одна, с точки зрения работы Докера выполняется два действия: создание контейнера и запуск. Существуют и более сложные варианты исполнения, но в этом разделе мы рассмотрим только базовые команды.

    Запустим nginx так, чтобы он работал в фоне. Для этого после слова run добавляется флаг -d :

    После её выполнения Докер выводит идентификатор контейнера и возвращает управление. Убедитесь в том, что nginx работает, открыв в браузере ссылку localhost:8080 . В отличие от предыдущего запуска, наш nginx работает в фоне, а значит не видно его вывода (логов). Посмотреть его можно командой docker logs , которой нужно передать идентификатор контейнера:

    Вы так же можете подсоединиться к выводу лога в стиле tail -f . Для этого запустите docker logs -f 431a3b3fc24bf8440efe2bca5bbb837944d5ae5c3b23b9b33a5575cb3566444e . Теперь лог будет обновляться каждый раз, когда вы обновляете страницу в браузере. Выйти из этого режима можно набрав Ctrl + C , при этом сам контейнер остановлен не будет.

    Теперь выведем информацию о запущенных контейнерах командой docker ps :

    • CONTAINER_ID — идентификатор контейнера. Так же, как и в git, используется сокращенная запись хеша.
    • IMAGE — имя образа, из которого был поднят контейнер. Если не указан тег, то подразумевается latest.
    • COMMAND — команда, которая выполнилась на самом деле при старте контейнера.
    • CREATED — время создания контейнера
    • STATUS — текущее состояние.
    • PORTS — проброс портов.
    • NAMES — алиас. Докер позволяет кроме идентификатора иметь имя. Так гораздо проще обращаться с контейнером. Если при создании контейнера имя не указано, то Докер самостоятельно его придумывает. В выводе выше как раз такое имя у nginx.

    (Команда docker stats выводит информацию о том, сколько ресурсов потребляют запущенные контейнеры).

    Теперь попробуем остановить контейнер. Выполним команду:

    Если попробовать набрать docker ps , то там этого контейнера больше нет. Он удален.

    Команда docker ps выводит только запущенные контейнеры. Но кроме них могут быть и остановленные. Причем, остановка может происходить как и по успешному завершению так и в случае ошибок. Попробуйте набрать docker run ubuntu ls , а затем docker run ubuntu bash -c «unknown» . Эти команды не запускают долго живущего процесса, они завершаются сразу по выполнению, причем вторая с ошибкой, так как такой команды не существует.

    Теперь выведем все контейнеры командой docker ps -a . Первыми тремя строчками вывода окажутся:

    Здесь как раз два последних наших запуска. Если посмотреть на колонку STATUS, то видно, что оба контейнера находятся в состоянии Exited. То есть запущенная команда внутри них выполнилась, и они остановились. Разница лишь в том, что один завершился успешно (0), а второй с ошибкой (127). После остановки контейнер можно даже перезапустить:

    Только в этот раз вы не увидите вывод. Чтобы его посмотреть воспользуйтесь командой docker logs determined_tereshkova .

    Взаимодействие с другими частями системы

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

    Interactive mode

    Самый простой вариант использования Докера, как мы уже убедились — поднять контейнер и выполнить внутри него какую либо команду:

    После выполнения команды Docker возвращает управление, и мы снова находимся вне контейнера. Если попробовать точно так же запустить баш, то мы получим не то что хотим:

    Мастер Йода рекомендует:  Где в интернете заработать реальные деньги

    Дело в том, что bash запускает интерактивную сессию внутри контейнера. Для взаимодействия с ней нужно оставить открытым поток STDIN и запустить TTY (псевдо-терминал). Поэтому для запуска интерактивных сессий нужно не забыть добавить опции -i и -t . Как правило их добавляют сразу вместе как -it . Поэтому правильный способ запуска баша выглядит так: docker run -it ubuntu bash .

    Ports

    Если запустить nginx такой командой docker run nginx , то nginx не сможет принять ни один запрос, несмотря на то, что внутри контейнера он слушает 80 порт (напомню, что каждый контейнер по умолчанию живет в своей собственной сети). Но если запустить его так docker run -p 8080:80 nginx , то nginx начнет отвечать на порту 8080.

    Флаг -p позволяет описывать как и какой порт выставить наружу. Формат записи 8080:80 расшифровывается так: пробросить порт 8080 снаружи контейнера в контейнер на порт 80. Причем, по умолчанию, порт 8080 слушается на 0.0.0.0 , то есть на всех доступных интерфейсах. Поэтому запущенный таким образом контейнер доступен не только через localhost:8080 , но и снаружи машины (если доступ не запрещен как нибудь еще). Если нужно выполнить проброс только на loopback, то команда меняется на такую: docker run -p 127.0.0.1:8080:80 nginx .

    Docker позволяет пробрасывать столько портов, сколько нужно. Например, в случае nginx часто требуется использовать и 80 порт и 443 для HTTPS. Сделать это можно так: docker run -p 80:80 -p 443:443 nginx Про остальные способы пробрасывать порты можно прочитать в официальной документации.

    Volumes

    Другая частая задача связана с доступом к основной файловой системе. Например, при старте nginx-контейнера ему можно указать конфигурацию, лежащую на основной фс. Докер прокинет её во внутреннюю фс, и nginx сможет её читать и использовать.

    Проброс осуществляется с помощью опции -v . Вот как можно запустить баш сессию из образа Ubuntu, подключив туда историю команд с основной файловой системы: docker run -it -v

    /.bash_history:/root/.bash_history ubuntu bash . Если в открытом баш понажимать стрелку вверх, то отобразится история. Пробрасывать можно как файлы так и папки. Любые изменения производимые внутри volume меняются как внутри контейнера, так и снаружи, причем по умолчанию доступны любые операции. Как и в случае портов, количество пробрасываемых файлов и директорий может быть любым.

    При работе с Volumes есть несколько важных правил, которые надо знать:

    • Путь до файла во внешней системе должен быть абсолютным.
    • Если внутренний путь (то, что идет после : ) не существует, то Докер создаст все необходимые папки и файл. Если существует, то заменит старое тем, что было проброшено.

    Кроме пробрасывания части фс снаружи, Докер предоставляет еще несколько вариантов создания и использования Volumes. Подробнее — в официальной документации.

    Переменные окружения

    Конфигурирование приложения внутри контейнера, как правило, осуществляется с помощью переменных окружения в соответствии с 12factors. Существует два способа их установки:

    • Флаг -e . Используется он так: docker run -it -e «HOME=/tmp» ubuntu bash
    • Специальный файл, содержащий определения переменных окружения, который пробрасывается внутрь контейнера опцией —env-file .

    Подготовка собственного образа

    Создание и публикация собственного образа не сложнее его использования. Весь процесс делится на три шага:

    • Создается файл Dockerfile в корне проекта. Внутри описывается процесс создания образа.
    • Выполняется сборка образа командой docker build
    • Выполняется публикация образа в Registry командой docker push

    Рассмотрим процесс создания образа на примере упаковки линтера eslint (не забудьте повторить его самостоятельно). В результате сборки, мы получим образ, который можно использовать так:

    То есть достаточно запустить контейнер из этого образа, подключив папку с файлами js для проверки как Volume во внутреннюю папку /app .

    1. Конечная структура папки, на основе файлов которой соберется образ, выглядит так:

    Файл eslintrc.yml содержит конфигурацию линтера. Он автоматически прочитывается если лежит в домашней директории под именем .eslintrc.yml . То есть этот файл должен попасть под таким именем в папку /root внутрь образа.

    2. Создание Dockerfile

    Dockerfile имеет довольно простой формат. На каждой строчке указывается инструкция (директива) и её описание.

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

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

    Основная инструкция в Dockerfile. Фактически здесь указывается sh команда, которая будет выполнена в рамках окружения, указанного во FROM при сборке образа. Так как по умолчанию все выполняется от пользователя root, то использовать sudo не нужно (и скорее всего его нет в базовом образе). К тому же учтите, что сборка образа — процесс не интерактивный. В тех ситуациях, когда вы используете команду, которая может запросить что-то от пользователя, необходимо подавлять этот вывод. Например, в случае пакетных менеджеров делают так: apt-get install -y curl . Флаг -y как раз говорит о том что нужно производиться установку без дополнительных вопросов.


    Технически образ Докера — это не один файл, а набор так называемых слоев. Каждый вызов RUN формирует новый слой, который можно представить как набор файлов, созданных и измененных (в том числе удаленных) командой, указанной в RUN. Такой подход позволяет значительно улучшить производительность системы, задействовав кеширование слоев, которые не поменялись. С другой стороны, Докер переиспользует слои в разных образах если они идентичны, что сокращает и скорость загрузки и занимаемое пространство на диске. Тема кеширования слоев довольно важная при активном использовании Докера. Для её эффективной работы нужно понимать как она устроена и как правильно описывать инструкции RUN для максимальной утилизации.

    В соответствии со своим названием команда COPY берет файл или папку из основной файловой системы и копирует её внутрь образа. У команды есть ограничение. То, что копируется, должно лежать в той же папке, где и Dockerfile. Именно эту команду используют при разработке когда необходимо упаковать приложение внутрь образа.

    WORKDIR

    Инструкция, устанавливающая рабочую директорию. Все последующие инструкции будут считать, что они выполняются именно внутри указанной папки. По сути она действует как команда cd . Кроме того, когда мы запускаем контейнер, то он также стартует из папки WORKDIR. Например, запустив bash вы окажетесь внутри неё.

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

    3. Сборка

    Для сборки образа используется команда docker build . С помощью флага -t передается имя образа, включая имя аккаунта и тег. Как обычно, если не указывать тег, то подставляется latest.

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

    4. Публикация

    Для успешного выполнения публикации нужно соблюсти два условия:

    • Зарегистрироваться на Docker Cloud и создать там репозиторий для образа.
    • Залогиниться в cli интерфейсе используя команду docker login .

    Docker Compose

    Docker Compose — продукт, позволяющий разрабатывать проект локально используя Докер. По решаемым задачам его можно сравнивать с Vagrant.

    Docker Compose позволяет управлять набором контейнеров, каждый из которых представляет из себя один сервис проекта. Управление включает в себя сборку, запуск с учетом зависимостей и конфигурацию. Конфигурация Docker Compose описывается в файле docker-compose.yml , лежащем в корне проекта, и выглядит примерно так:

    В бою

    При использовании Докера настройка машин проекта, как правило, сводится к установке Докера. Дальше нужно только деплоить. Простейший процесс выкладки выглядит так:

    1. Скачать новый образ.
    2. Остановить старый контейнер.
    3. Поднять новый контейнер.

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

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

    Докер под капотом

    Изоляция, которую предоставляет Докер, достигается благодаря возможностям ядра Cgroups и Namespaces. Они позволяют запускать процесс операционной системы не только в изолированном окружении, но и с ограничением по использованию физических ресурсов, таких как памяти или процессора.

    Использование Docker в разработке

    Наш Java-разработчик Константин одинаково охотно изучает новые технологии и делится приобретенными знаниями. Одно из последних его открытий — Docker для разработки. Преимущества и недостатки использования этой технологии при разработке Костя описал в своем блоге, а мы теперь делимся с вами.

    Многие признаются, что, начав использовать Docker, практически не могут потом от него отказаться. Я абсолютно с этим согласен. Применение Docker в разработке сократило количество ошибок конфигурации в нашем проекте, позволяя посвящать больше времени написанию кода, нежели поиску причин, по которым часть проекта не работает. Это очень эффективно, особенно если проект состоит из нескольких частей, над которыми работают разные разработчики, например, фронтенд и бэкенд. В таком случае нежелательно тратить время фронтенд-разработчика на поиск недостающего пакета или строчки конфигурационного файла (или любой другой проблемы) для того, чтобы работал бэкенд. Docker решает подобные проблемы. Более того, разработчику больше не нужно самостоятельно настраивать окружение проекта, так что время для знакомства с проектом также сокращается. Данный пост представляет собой небольшой совет: как начать использовать Docker в проекте.

    ЧТО ОЖИДАЕТСЯ ОТ DOCKER

    Стандартный способ знакомства с новым проектом — следующий:

    1. Подготовка окружения согласно требованиям (OS и настройки);
    2. Клонирование проекта;
    3. Установка пакетов, необходимых для разработки (например, nodejs, gradle, maven и т.д.);
    4. Подготовка проекта к запуску (копирование директорий, симлинков, настройка конфигураций, хостов и т.д.).

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

    Способ, предполагающий использование Docker, несколько проще:

    1. Клонирование проекта;
    2. Скачивание или создание Docker-образа;
    3. Запуск контейнера на основе этого образа.

    После этого шага контейнер функционирует как “виртуальная машина”, где все внутри уже приготовлено для разработки. Нужно всего лишь запустить скрипт, чтобы запустить проект. Более того, если кто-то случайно что-то сломал, контейнер легко может быть перезапущен из первоначального состояния.

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

    ПРОСТОЙ ПРИМЕР

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

    Эта команда делает проект доступным на localhost:4000 . Ctrl+C останавливает сервер. Для запуска команды мне нужны:

    • установленный Jekyll,
    • установленный плагин Jekyll для пагинации,
    • исходный код.

    Чтобы настроить это окружение, я создаю Dockerfile в корне проекта.

    Каждая команда в этом файле создает Docker-слой. Хорошая практика — уменьшение количества слоёв, то есть команд в Dockerfile , вот почему команда RUN совершает сразу три действия. Также лучше фиксировать версии везде, где можно, чтобы избежать появления проблем впоследствии из-за обновления пакетов.

    Теперь с помощью этого файла можно создать образ:

    Вместо этого шага образ может быть загружен из Docker registry. Конечно, для этого нужно, чтобы кто-то ранее создал и запушил его туда.

    После этого можно запустить контейнер с использованием образа:

    Эта команда создаёт контейнер со следующими параметрами:

    • myblog — имя контейнера;
    • [clone-dir] установлен в /root/src файловой системы контейнера. Это будет что-то вроде расшаренной папки на виртуальной машине, так что файлы на хосте и в контейнере всегда будут идентичными;
    • порт 4000 контейнера будет соответствовать порту 4000 хоста. Таким образом localhost:4000 будет перенаправлять на порт 4000 контейнера;
    • private/myblog — это имя образа;
    • /bin/bash — команда, которая будет выполняться в контейнере.

    Последний пункт довольно важен. По завершении этой команды контейнер будет остановлен. /bin/bash не останавливается никогда, гарантируя, что мой контейнер будет работать, пока я сам не остановлю его. Команда /bin/bash не делает ничего полезного, просто отдает консоль, поэтому после мне нужно запустить сервер самостоятельно:

    После этого сервер будет доступен на localhost:4000 на хосте.

    Мне нравится этот подход, я считаю, что разработчик должен контролировать запуск сервера, перезапускать его при необходимости, конфигурировать и так далее. Но если я собираюсь передать этот контейнер кому-то ещё (например, другому разработчику, которому нужен мой запущенный сервер, но не в продакшн), я использую ‘ docker run ’ с командой, которая запускает сервер:

    УПРОЩАЕМ

    Мне не нравится писать команду запуска. Она очень длинная, имеет множество опций, и мне приходится запоминать порты, папки и имена. Совсем сложно все становится, когда контейнеров нужно запустить несколько, организовав между ними сеть. Проект Docker compose помогает упростить процесс.

    Файл docker-compose.yml (в корне) имеет следующую структуру:

    Команда ниже идентична команде ‘ docker run ’, описанной выше.

    Довольно удобно для пользователя, не так ли?

    НЕСКОЛЬКО КОНТЕЙНЕРОВ ДЛЯ РАЗРАБОТКИ

    Представим, что проект состоит из фронтенда и бэкенда. Фронтенд-разработчики хотят, чтобы сервер работал, но не желают ничего знать о нём. Более того, они не готовы даже его запускать. Бэкенд-разработчики тоже не горят желанием разбираться во фронтенде. Некоторые вообще не хотят заниматься ни фронтендом, ни бэкендом, все должно запускаться само. А кто-то, наоборот, хочет контролировать все части приложения.

    Идея создания окружения в следующем: фронтенд запускается на порту 4200. Бэкенд использует порт 8080. Для передачи API-запросов между фронтендом и бэкендом используется прокси (4200->8080). Я хочу поместить фронтенд и бэкенд в отдельные контейнеры (в этом примере бэкенд запускается на jetty, а клиентское приложение — это angular2 приложение):

    Каждый контейнер имеет volume, который содержит исходный код. Контейнер для бэкэнда отвечает за серверное веб-приложение, которое доступно на порту 8080 извне. Контейнер для фронтенда отвечает за клиентское приложение, например, на angular2, он имеет открытый порт 4200 для доступа к приложению с хоста. В нем же содержится прокси для перенаправления API запросов. При такой конфигурации на хосте порты 8080 и 4200 эквиваленты для запросов API.

    Я использую следующую структуру файлов:

    frontend — это каталог в корне проекта, proxy-config.json — файл, описывающий прокси. Это особый файл angular cli, можно использовать и другую сконфигурированную прокси.

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

    При использовании docker compose вы автоматически можете использовать внутреннюю сеть Docker для доступа к другим контейнерам. Ниже пример конфигурации прокси, где я использую название сервиса на бэкенде, объявленное в файле docker-compose.yml.

    Надо заметить, что для обращения к контейнеру по внутренней сети не обязательно открывать порт наружу.

    ВЫВОДЫ

    Если вы не используете Docker при разработке, то эти причины должны убедить вас начать:

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

    Что же касается недостатков, я нашёл следующие:

    • возможен только удалённый дебаггинг. Это довольно удобно для java-проектов с использованием Idea, но при использовании других стеков инструментов может повлечь за собой проблемы;
    • Запуск графических приложений. Если процесс разработки требует запуск UI-приложений (например, e2e тесты в chrome), сделать это будет непросто;
    • профилирование. Например, JVM в контейнере нельзя увидеть с хоста. К счастью, многие профайлеры имеют возможность запустить своего агента в контейнере, подключиться к нему через сеть и профайлить как обычно.

    Другими словами, при использовании Docker всё становится удалённым — и это надо иметь в виду.

    Для меня Docker был шагом к изучению создания кластеров и микросервисов: ещё одно модное и перспективное на сегодняшний день направление. А недавно Docker включил в себя проект Docker swarm, который позволяет с легкостью разворачивать кластер на нескольких машинах и управлять им.

    Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

    Docker, часть 2 – работа с контейнерами

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

    Команды для работы с контейнерами имеют следующий синтаксис:

    Рассмотрим некоторые из них более подробно.

    Создание и запуск контейнеров

    Запомните основные постулаты контейнеров в docker

    1. Контейнер живет, пока живет процесс, вокруг которого рождается контейнер.
    2. Внутри контейнера этот процесс имеет p >Создание контейнера


    -a – сокращение от –attach (прикрепить). Контейнер можно прикрепить к стандартным потокам STDIN, STDOUT или STDERR.
    Запуск существующего контейнера (можно обращаться к контейнеру по идентификатору или имени):

    Определить идентификатор или имя можно при помощи команды ps. Опция «–l» означает последний запущенный контейнер:

    Как уже было рассмотрено в предыдущей части, команда run объединяет создание и запуск контейнера. Для краткости с ней можно не указывать слово container.

    Для запуска внутри контейнера команды:

    Запуск в фоновом режиме

    -d – это сокращение от –detach (отсоединить). Контейнер будет работать в фоновом режиме, и вы сможете использовать терминал для других команд.

    Присвоение имени

    Чтобы не приходилось узнавать и запоминать идентификатор контейнера, при создании можно назначать каждому контейнеру уникальное имя, используя опцию командной строки —name, как в следующем примере:

    После этого можно работать с контейнером (выполнять команды start, stop, remove, top, stats), обращаясь к нему по имени, например:

    docker start myname – запуск контейнера
    docker stats myname – отображение статистики использования ресурсов
    docker top myname – отображение запущенных в контейнере процессов

    Если вы попытаетесь выполнить например команду top, из выше указанного примера то получите ошибку

    Я думаю если вы внимательно читали статью то сможете сами ответить почему возникает эта ошибка.

    Запуск интерактивного сеанса

    Для интерактивного подключения к оболочке контейнера и запуска команд, как в обычной системе Linux, нужно создать контейнер со следующими опциями:

    Структура этой команды следующая:

    -i задает запуск интерактивного сеанса.
    -t выделяет TTY и подключает стандартные потоки ввода и вывода.
    ubuntu – образ, используемый для создания контейнера.
    bash (или /bin/bash) – запускаемая в контейнере Ubuntu команда.

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

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

    Если вы хотите запустить контейнер в режиме демона используйте опцию ‘-d’.

    Для повторного подключения к запущенному контейнеру требуется знать его идентификатор или имя. Для этого запустите команду docker ps, а затем выполните docker attach, указав идентификатор или имя.

    Проверка состояния контейнеров

    Если у вас запущено несколько контейнеров Docker, и вы хотите выбрать, с каким именно работать, потребуется вывести их список. Для этого применяется команда ls. Помимо вывода списка контейнеров она выводит также полезную информацию о них. Команда без опций выдает список запущенных контейнеров:

    Опция ‘-a’ указывает команде выводить все контейнеры, а не только запущенные, опция -s выводит размер каждого контейнера:

    Команда inspect выдает множество полезной информации о контейнере:

    Для вывода логов контейнера выполните команду logs:

    Остановка контейнера

    Обычно контейнер завершается автоматически после завершения процесса, но иногда требуется собственноручно завершить запущенный контейнер. Команда stop осуществляет «мягкое» завершение контейнера, по умолчанию предоставляя 10 секунд для завершения всех процессов:

    Для немедленного завершения выполните команду kill. В большинстве ситуаций stop предпочтительнее.

    Немедленное завершение всех запущенных контейнеров:

    Удаление контейнера

    удаление заданного контейнера.

    удалить все не запущенные контейнеры.

    Изменения в контейнере

    Как уже отмечалось в начале, после остановки контейнера все изменения сделанные в нем удаляются. Это не совсем удобно, что же делать если нам нужно сохранить изменения? Для этого мы можем создать собственный контейнер взяв за основу уже готовый. Запустив интерактивный сеанс, мы можем работать в контейнере как на обычной Linux-машине и вносить любые необходимые изменения, например, устанавливать нужные пакеты. Допустим, нам требуется контейнер Ubuntu с сервером Nginx. Установим необходимые для этого программы:

    Теперь нужно сохранить эти изменения, чтобы в следующий раз у нас был контейнер, где уже есть все необходимое. Для этого сначала нужно выйти из контейнера, выполнив команду exit, а затем подтвердить сделанные изменения командой commit:

    Где идентификатор – это тот идентификатор, который использовался для первоначального запуска, а new-template – назначенное нами имя нового образа. Теперь он будет виден, если выполнить команду docker images:

    Созданный нами новый образ готов к использованию со всеми сделанными изменениями. Кроме того, мы можем отправить его в Docker Hub, чтобы при необходимости загружать его в других местах. Для этого войдите в свою учетную запись и воспользуйтесь командой push:

    где имя_пользователя – имя, соответствующее вашему аккаунту.

    Заключение

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

    Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

    Большой Docker FAQ: отвечаем на самые важные вопросы

    Содержание статьи

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

    Как управлять ресурсами, доступными для контейнера (процессор, память)?

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

    С процессором все несколько сложнее. Docker полагается на механизм cgroups для ограничения ресурсов процессора, а он оперирует понятием веса, которое может быть от 1 до 1024. Чем выше вес группы процессов (в данном случае контейнера), тем больше шансов у нее получить процессорные ресурсы. Другими словами, если у тебя будет два контейнера с весом 1024 и один с весом 512, то первые два будут иметь в два раза больше шансов получить ресурсы процессора, чем последний. Это нечто вроде приоритета. Значение по умолчанию всегда 1024, для изменения используется опция -c:

    Также доступна опция —cpuset, с помощью которой контейнер можно привязать к определенным ядрам процессора. Например, если указать —cpuset=»0,1″, то контейнеру будут доступны первые два ядра. Просмотреть статистику использования ресурсов можно с помощью команды docker stats:

    Что такое линковка контейнеров и почему она хуже DNS discovery?

    Линковка контейнеров — это встроенный в Docker механизм, позволяющий пробрасывать информацию об IP-адресе и открытых портах одного контейнера в другой. На уровне командной строки это делается так:

    Данная команда запускает контейнер www с веб-сервером nginx внутри и пробрасывает внутрь него инфу о контейнере с именем db. При этом происходит две вещи:

    1. В контейнере www появляется ряд переменных окружения, таких как DB_PORT_8080_TCP_ADDR=172.17.0.82, DB_PORT_8080_TCP_PORT=1234 и DB_PORT_8080_TCP_PROTO=tcp, по три на каждый открытый порт в контейнере db. Эти переменные можно использовать в файлах конфигурации и скриптах, чтобы связать контейнер www с db.
    2. Файл /etc/hosts контейнера www автоматически обновляется, и в него попадает информация об IP-адресе контейнера db (в данном примере строка 172.17.0.82 db). Это позволяет использовать хостнейм вместо айпишника для обращения к контейнеру db из контейнера www.

    Казалось бы, это именно то, что нужно, и без всяких заморочек со SkyDNS. Но данный метод имеет ряд проблем. Первая: обновление записей в /etc/hosts происходит только один раз, а это значит, что, если после перезапуска контейнер db получит другой IP-шник, контейнер www его не увидит (возможно, когда ты читаешь эти строки, проблема уже исправлена). Вторая: хостнеймы видны только изнутри слинкованного контейнера (адресата), поэтому для доступа в обратную сторону, а также из хост-системы и тем более с другой машины все так же придется использовать IP-адреса. Третья: при большом количестве контейнеров и связей между ними настройка с помощью —link чревата ошибками и очень неудобна. Четвертая: линковка не имеет побочного эффекта в виде балансировки нагрузки.

    Можно ли управлять Docker через веб-интерфейс?

    Официального GUI для Docker не существует. Однако можно найти несколько интересных проектов, решающих эту проблему. Первый — это DockerUI, очень простой веб-интерфейс, распространяемый в виде Docker-образа. Для установки и запуска выполняем такую команду:

    Сам интерфейс будет доступен по адресу http://IP-dockerd:9000. В случае необходимости подключиться к другому хосту с запущенным dockerd просто указываем его адрес:порт с помощью опции -e:

    Другой вариант — это Shipyard, включающий в себя такие функции, как аутентификация, поддержка кластеров и CLI. Основное назначение интерфейса — управление кластерами из множества Docker-хостов. Как и в предыдущем случае, установка очень проста:

    Веб-интерфейс будет доступен на порту 8080, юзер admin, пароль shipyard.

    Хакер #196. Все о Docker

    Я слышал, что вместо docker exec лучше использовать SSH. Почему?

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

    • Во-первых, SSH не имеет проблемы «повисших процессов», когда по какой-то причине при выполнении docker exec клиент Docker убивается или падает, а запущенная им команда продолжает работать.
    • Во-вторых, для выполнения команды внутри контейнера клиент Docker должен иметь права root, чего не требует клиент SSH. Это вопрос не столько удобства, сколько безопасности.
    • В-третьих, в Docker нет системы разграничения прав на доступ к контейнерам. Если тебе понадобится дать кому-то доступ к одному из контейнеров с помощью docker exec, придется открывать полный доступ к docker-хосту.

    Доступ к Docker можно получить из контейнера. Достаточно пробросить внутрь него UNIX-сокет:

    У меня сложная настройка с зависимостями между контейнерами, поэтому —restart мне не подходит

    В этом случае следует использовать стандартную систему инициализации дистрибутива. В качестве примера возьмем сервис MySQL. Чтобы запустить его внутри Docker на этапе инициализации Red Hat, CentOS и любого другого основанного на systemd дистрибутива, нам потребуется следующий unit-файл (mysql меняем на имя нужного контейнера):

    Копируем его в каталог /etc/systemd/system/ под именем docker-mysql.service и активируем:

    В Ubuntu та же задача выполняется немного по-другому. Создаем файл /etc/init/docker-mysql.conf:

    А далее отдаем команду Upstart перечитать конфиги:

    А теперь самое главное. Чтобы поставить другой сервис в зависимость от этого, просто создаем новый конфиг по аналогии и меняем строку After=docker.service на After=docker-mysql.service в первом случае или меняем строку start on filesystem and started docker на start on filesystem and started docker-mysql во втором.

    Периодически некоторые мои контейнеры наполняются зомби-процессами. Почему так происходит?

    Это одна из фундаментальных проблем Docker. В UNIX-системах в зомби превращается некорректно остановленный процесс, завершения которого до сих пор ждет родитель, — процесса уже нет, а ядро все равно продолжает хранить о нем данные. В нормальной ситуации зомби существуют недолго, так как сразу после их появления ядро пинает родителя (сигнал SIGCHLD) и тот разбирается с мертвым потомством. Однако в том случае, если родитель умирает раньше ребенка, попечительство над детьми переходит к первичному процессу (PID 1) и разбираться с зомби, в которых могут превратиться его подопечные, теперь его проблема.

    В UNIX-системах первичный процесс — это демон init (или его аналог в лице Upstart или systemd), и он умеет разбираться с зомби корректно. Однако в Docker, с его философией «одно приложение на один контейнер» первичным процессом становится то самое «одно приложение». Если оно порождает процессы, которые сами порождают процессы, а затем умирают, попечительство над внуками переходит к главному процессу приложения, а оно с зомби (если они появятся) справляться совсем не умеет (в подавляющем большинстве случаев).

    Решить означенную проблему можно разными способами, включая запуск внутри контейнера Upstart или systemd. Но это слишком большой оверхед и явное излишество, поэтому лучше воспользоваться образом phusion/baseimage (на основе последней Ubuntu), который включает в себя минималистичный демон my_init, решающий проблему зомби-процессов. Просто получаем образ из Docker Hub и используем его для формирования образов и запуска своих приложений:

    Кроме my_init, baseimage включает в себя также syslog-ng, cron, runit, SSH-сервер и фиксы apt-get для несовместимых с Docker приложений. Плюс поддержка скриптов инициализации, которые можно использовать для запуска своих сервисов. Просто пропиши нужные команды в скрипт и положи его в каталог /etc/my_init.d/ внутри контейнера.

    Почему, собирая образ с помощью Dockerfile, я получаю толстый слоеный пирог?

    Команда docker build собирает образ из инструкций Dockerfile не атомарно, а выполняя каждую команду по отдельности. Работает это так: сначала Docker читает команду FROM и берет указанный в ней образ за основу, затем читает следующую команду, запускает контейнер из образа, выполняет команду и делает commit, получая новый образ, затем читает следующую команду и делает то же самое по отношению к сохраненному в предыдущем шаге образу. Другими словами, каждая команда Dockerfile добавляет новый слой к существующему образу, поэтому стоит избегать длинных списков команд вроде таких:

    А вместо этого писать все одной строкой:

    Ну и в целом не особо увлекаться составлением длинных Dockerfile. Кстати, в Docker есть лимит на количество слоев, и он равен 127. Это искусственное ограничение, введенное с целью не допустить деградации производительности при большом количестве слоев и не позволить админам использовать саму идею слоев не по назначению.

    Правильно написанный Dockerfile

    Docker поддерживает различные механизмы сборки контейнера из слоев. В чем их различия?

    Текущая версия Docker (1.5.0) поддерживает пять различных механизмов для сборки файловой структуры контейнера из слоев: AUFS, Device Mapper, BTRFS, overlay и VFS. Посмотреть, какая технология используется в текущий момент, можно с помощью команды docker info, а выбрать нужную — с помощью флага -s при запуске демона. Различия между технологиями следующие:

    • AUFS — технология, применявшаяся в Docker с первых дней существования проекта. Отличается простотой реализации и очень высокой скоростью работы, однако имеет некоторые проблемы с производительностью при открытии громоздких файлов на запись и работе в условиях большого количества слоев и каталогов. Огромный минус: из мейнстримовых дистрибутивов доступна только в ядрах Debian и Ubuntu.
    • Device Mapper — комплексная подсистема ядра Linux для создания RAID, шифрования дисков, снапшотинга и так далее. Главное преимущество в том, что Device Mapper доступен в любом дистрибутиве и в любом ядре. Недостаток — что Docker использует обычный заполненный нулями файл для хранения всех образов, а это приводит к серьезным проседаниям производительности при записи файлов.
    • Btrfs — позволяет реализовать функциональность AUFS на уровне файловой системы. Отличается высокой производительностью, но требует, чтобы каталог с образами (/var/lib/docker/) находился на Btrfs.
    • Overlay — альтернативная реализация функциональности AUFS, появившаяся в ядре 3.18. Отличается высокой производительностью и не имеет ярко выраженных недостатков, кроме требования к версии ядра.
    • VFS — самая примитивная технология, опирающаяся на стандартные механизмы POSIX-систем. Фактически отключает механизм разбиения на слои и хранит каждый образ в виде полной структуры каталога, как это делает, например, LXC или OpenVZ. Может пригодиться, если есть проблема вынесения часто изменяемых данных контейнера на хост-систему.


    По умолчанию Docker использует AUFS, но переключается на Device Mapper, если поддержки AUFS в ядре нет.

    В большинстве случаев Docker будет работать поверх Device Mapper

    Расскажите подробнее про Docker Machine, Swarm и Compose

    Это три инструмента оркестрации, развиваемых командой Docker. Они все находятся в стадии активной разработки, поэтому пока не рекомендуются к применению в продакшене. Первый инструмент, Docker Machine позволяет быстро развернуть инфраструктуру Docker на виртуальных или железных хостах. Это своего рода инструмент zero-to-Docker, превращающий ВМ или железный сервер в Docker-хост. Бета-релиз Machine уже включает в себя драйверы для двенадцати различных облачных платформ, включая Amazon EC2, VirtualBox, Google Cloud Platform и OpenStack.

    Главная задача Machine — позволить системному администратору быстро развернуть кластер из множества Docker-хостов без необходимости заботиться о добавлении репозиториев, установке Docker и его настройке; все это делается в автоматическом режиме. Разработчикам и пользователям Machine также может пригодиться, так как позволяет в одну команду создать виртуальную машину с минимальным Linux-окружением и Docker внутри. Особенно это полезно для юзеров Mac’ов, так как они могут не заморачиваться с установкой Docker с помощью brew или boot2docker, а просто выполнить одну команду:

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

    Swarm распространяется в виде контейнера, поэтому создать новый кластер с его помощью можно за считаные секунды:

    Работая со Swarm, ты всегда будешь иметь дело с сервером Swarm, а не с отдельными контейнерами, которые теперь будут именоваться нодами. На каждой ноде будет запущен агент Swarm, ответственный за принятие команд от сервера. Команды будут выполнены сразу на всех нодах, что позволяет разворачивать очень большие фермы однотипных контейнеров.

    Третий инструмент, Docker Compose (в девичестве fig) позволяет быстро запускать мультиконтейнерные приложения с помощью простого описания на языке YAML. В самом файле можно перечислить, какие контейнеры и из каких образов должны быть запущены, какие между ними должны быть связи (используется механизм линковки), какие каталоги и файлы должны быть проброшены с хост-системы. К примеру, конфигурация для запуска стека LAMP из примера в предыдущей статье будет выглядеть так:

    Все, что нужно сделать для его запуска, — просто отдать такую команду:

    Но что более интересно — ты можешь указать, сколько контейнеров тебе нужно. Например, ты можешь запустить три веб-сервера и две базы данных:

    Выводы

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

    У Docker прекрасная встроенная справка

    Несколько простых советов

    • Всегда выноси часто изменяемые данные на хост-систему. Логи, базы данных, каталоги с часто меняющимися файлами — все это не должно храниться внутри контейнера (во-первых, усложняется администрирование, во-вторых, при остановке контейнера данные потеряются). В идеале контейнер должен содержать только код, конфиги и статичные файлы.
    • Не лепи новые слои при каждом изменении настроек или обновлении софта внутри контейнера. Используй вместо этого Dockerfile для автоматической сборки нового образа с обновлениями и измененными конфигами.
    • Вовремя вычищай завершенные и давно не используемые контейнеры, чтобы избежать возможных конфликтов имен.
    • По возможности используй SkyDNS или dnsmasq. Их несложно поднять, но они способны сэкономить уйму времени.
    • Внимательно изучи хелп по команде run (docker run —help), там много интересного и полезного.

    Шпаргалка по командам Dockerfile

    • FROM — какой образ использовать в качестве базы (должна быть первой строкой в любом Dockerfile).
    • MAINTAINER — имя мантейнера данного Dockerfile.
    • RUN — запустить указанную команду внутри контейнера.
    • CMD — выполнить команду при запуске контейнера (обычно идет последней).
    • EXPOSE — список портов, которые будет слушать контейнер (используется механизмом линковки).
    • ENV — создать переменную окружения.
    • ADD — скопировать файл/каталог внутрь контейнера/образа (первый аргумент может быть URL).
    • ENTRYPOINT — команда для запуска приложения в контейнере (по умолчанию /bin/sh -c).
    • VOLUME — пробросить в контейнер указанный каталог (аналог опции -v).
    • USER — сменить юзера внутри контейнера.
    • WORKDIR — сменить каталог внутри контейнера.
    • ONBUILD [ИНСТРУКЦИЯ] — запустить указанную инструкцию Dockerfile только в том случае, если образ используется для сборки другого образа (с помощью FROM).

    Евгений Зобнин

    Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.

    Docker + Docker Compose – запуск контейнеров для вебразработки

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

    Docker был создан в 2013 году для собственных нужд компании dotCloud (Paas платформа). За пять лет своего существования Docker стал одним из самых популярных стартапов в виду своей полезности и удобности как для разработки так и для использования в продакшене. На текущий момент начиная работу над серьёзным проектом в команде, вам почти наверника предложат развернуть окружения для него именно в докере.

    Нужно ли изучать докер?

    2020 год для Docker Inc выдался не особо удачным ввиду внутрикомандных разногласий и судя по блогам создателей — в компании есть небольшие проблемы с определением курса её дальнейшего развития (об этом можно почитать на хабре в статье с громким названием — Докер мертв). Тем не менее Docker остается популярен, в большинстве вакансий уровня выше junior, знание докера чаще может является хоть и не основным, но желательным требованием. К тому же многих устраивает текущий инструментарий и менять его нет смысла (список аналогичных Докеру систем).

    У докера есть ряд преимуществ и особенностей который обычно выделяют в следующий список:

    • Быстрое развертывание и загрузка боевого окружения;
    • Масштабируемость — локальная машина разработчика или кластер с системой оркестрации и балансировкой нагрузки;
    • Модульность — отдельные контейнеры или микросервисная архитектура вашего приложения;
    • и другие достоинство можно посмотреть здесь.

    Иными словами для разработчика докер хорош тем, что вам не надо настраивать сервер и каждый раз устанавливать разные компоненты, долго их конфигурировать, да ещё пытаться создать окружение, которое будет похоже на боевое, да ещё и ставить разные компонеты в отдельности для каждого проекта захламляя основную ОС и создавая конфликты между установленными пакетами. С Docker, вы просто заполняете конфигурационный файл и командой в консоли запускаете «виртуалку» с вашим проектом. После чего, текущую конфигурацию можно будет также развернуть на собственном сервере или на облачных платформах типа Amazon Web Server. Либо эту же конфигурацию запустить на другом проекте и Docker будет переиспользовать контейнеры, которые у него уже есть.

    Docker — установка

    Для каждой системы установка докера несколько отличается. Инструкции для разных ОС на официальном сайте:

    Официально докер не поддерживает Windows 7, но с помощью Docker Toolbox установить можно, хотя и будет использоваться VirtualBox. Также подробнее остановимся на установке Docker в Linux, а именно в дистрибутив Debian. Кроме того помимо Docker, установим Docker Compose для того чтобы управлять докер контейнерами.

    Установка Docker и Docker Compose на Debian 9

    1 — Установим необходимые компоненты

    Как сократить ссылку: обзор 11 сервисов

    Время чтения: 9 минут Нет времени читать? Нет времени?

    Сокращатели URL – это сервисы, которые позволяют преобразовать длинные адреса в более короткие и удобные. 30 марта 2020 Google окончательно закрыл один из самых популярных – Google URL Shortener (goo.gl). Однако остались еще 11 инструментов, с помощью которых можно сокращать ссылку. Разбираем их функциональность и тарифы.

    1. is.gd

    Is.gd – англоязычный бесплатный сокращатель ссылок от сайта Memset.

    Длинную ссылку вида http://texterra.ru/blog/pochemu-kopirayteram-pora-perestat-slushat-marketologov-i-poyti-uchitsya-pisatelskomu-masterstvu.html он легко сокращает до https://is.gd/NH3ywp. Чтобы отследить статистику, при создании ссылки нажимаем на «Further options» и ставим галочку «Log statistics for this link».

    В статистике можно посмотреть число переходов по ссылке и отсортировать их по дате, стране, браузеру и т. д. Для просмотра статистики после создания ссылки нажимаем на «I want to see statistics for this URL».

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

    2. Bit.do

    Сервис bit.do был создан бразильской интернет-компанией Insite. Сами разработчики выделяют следующие преимущества:

    • Возможность регистрации собственного домена, например, yourshortna.me. Базовый тариф обойдется в 85 долларов в месяц, а Enterprise будет стоить 250 долларов.
    • Статистика по популярности и кликабельности вашей ссылки, в том числе по отдельным странам и городам.
    • Возможность задать короткое имя ссылки.
    • Созданные ссылки навсегда останутся рабочими.

    Испытаем сервис: вставляем в строку ссылку, которую хотим сократить – http://texterra.ru/blog/kak-proanalizirovat-dostizhenie-tseley-v-google-analytics-pri-nepravilnykh-nastroykakh.html, задаем ей сокращенное имя, нажимаем кнопку «Shorten».

    Получаем две ссылки и QR-код:

    Первая ссылка – укороченная версия исходной: http://bit.do/GoogleAnalytics. Другая показывает аналитику:

    Сервис довольно простой и удобный, главные плюсы – подробная аналитика и возможность задать собственное имя ссылки.

    3. Bitly.com

    Bitly – один из самых популярных сервисов для сокращения URL.

    Bitly не просто сокращает ссылки, но и предоставляет статистику переходов по ним. Для ее получения нужно зарегистрироваться или зайти через Twitter или Facebook. Или просто добавить знак плюса к сокращенному URL, вставить в адресную строку браузера и перейти.

    При создании ссылки можем дать ей короткое имя, для этого вводим его в разделе «Customize». Сервис уверяет: кастомные ссылки дают на 34 % больше кликов.

    Существует и платная версия – ее стоимость начинается от 29 $ в месяц и зависит от количества обычных и пользовательских ссылок, продолжительности их действия и сохранения отчетности.

    По моему мнению, это отличное, стабильно работающее приложение с множеством функций.

    4. Tiny URL.com

    Tiny URL был запущен в 2002 году, это один старейших и популярнейших сервисов по сокращению ссылок. С ним какое-то время работал «Твиттер», пока сначала не перешел на bit.ly, а затем не разработал собственную автоматическую систему t.co.

    Для начала вводим адрес ссылки. В поле «Custom alias» вы можете изменить URL на уникальный. Для этого нужно указать название, которое хотим дать ссылке.

    Сервис довольно удобный и простой, хорошо справляется со своей задачей.

    5. U.to

    U.to – русскоязычный сервис по сокращению ссылок.

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


    Для просмотра статистики по ссылке нужно нажать на соответствующую кнопку.

    В целом, сервис довольно простой, хотя устаревший. Особенно бесит форма регистрации, она у него самая долгая по сравнению с другими.

    6. Cutt.us

    У сервиса Cutt.us существует две версии.

    Первая – стандартный сокращатель ссылок. Вставляем http://texterra.ru/blog/rekruting-kak-marketing-ili-konvertiruem-soiskateley-v-pokupateley.html → задаем уникальное имя ссылки в строке «Suffix» → нажимаем «Cut».

    Получаем короткую ссылку http://cutt.us/recruit и QR-код.

    Вторая версия сервиса Smart Multi URL Shortener предназначена для обработки сразу нескольких длинных ссылок. Вводим три URL и задаем уникальное имя «helloblog». В итоге получается:

    Нажимаем «Gooo. » и получаем несколько сокращенных ссылок.

    Главная особенность сервиса – возможность создания сразу нескольких ссылок, что довольно удобно, хотя сервис показался более медленным, чем остальные в обзоре.

    7. Vk.com/cc

    Vk.cc – официальное приложение VK для сокращения ссылок. Доступно только зарегистрированным пользователям «ВКонтакте», однако созданные в нем ссылки можно использовать и вне этой соцсети.

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

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

    Приложение нравится своей простотой и стабильностью работы.

    8. Clck.ru

    В 2010 году «Яндекс» запустил свой собственный сервис по сокращению ссылок – «Кликер».

    Сервис русскоязычный и достаточно простой.

    «Для настоящих гиков» сайт предлагает следующее:

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

    Сервис хорошо и стабильно работает, неудобство заключается только в отсутствии аналитики.

    9. Lnnkin

    Lnnkin – еще один зарубежный сокращатель ссылок. Можно задать кастомный URL вида lnnk.in/@shlink, плюс даже защитить ссылку паролем.

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

    Есть платная подписка для тех, кому нужно, например, редактировать более 5 ссылок или быстро создавать через API свыше 5 000 ссылок в месяц. Но в целом хватит бесплатных возможностей, ведь нет ограничений на количество обычных коротких и пользовательских URL, все ссылки с пожизненным сроком действия.

    Кстати, у Lnnkin есть еще расширение для Chrome, позволяющее сокращать ссылки прямо из вкладки браузера.

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

    10. Rebrandly

    Rebrandly помогает превратить «длинные, уродливые и непроизносимые» URL-адреса в кастомные фирменные ссылки.

    Чтобы сократить ссылку, нужно:

    1. Зарегистрироваться.
    2. Вставить URL на главной и нажать кнопку «Rebrand». Или кликнуть на «New link» в разделе «Links», затем указать ссылку.
    3. Выбрать способ сокращения: генерировать самый короткий адрес, SEO-дружественный (учитывающий слова в URL) или, например, абсолютно случайный.
    4. Указать домен – оставить rebrand.ly или прикрепить собственный.
    5. Добавить к исходной ссылке UTM-метки, если это необходимо.

    Бесплатная статистика ограничена количеством кликов. Чтобы проводить подробную аналитику (следить за географией, устройствами, языками), а также подключать несколько доменных имен, постить сокращенные ссылки тысячами, строить отчеты – придется платить. Минимальный тариф стоит 29 $ в месяц.

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

    11. To.click

    To.click – мощный инструмент для создания ссылок трех типов: простые сокращенные, таргетированные (с пикселем, например, от «Фейсбука») и диплинки (для перехода на конкретную страницу внутри приложения). По умолчанию URL начинается с clc.to, но также можно подключить свой домен.

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

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

    В обзоре перечислены сервисы-сокращалки, которые мне показались интересными, но их гораздо больше. Какими пользуетесь вы? Поделитесь в комментариях.

    7 сервисов для сокращения ссылок Материал редакции

    Которые помогут заменить Google URL Shortener после его закрытия.

    13 апреля 2020 года Google начнёт ограничивать доступ к сервису goo.gl, а 30 марта 2020 года окончательно прекратит поддержку платформы. Рассказываем о восьми сервисах для сокращения ссылок, которые могут стать альтернативой Google URL Shortener.

    «Кликер» от «Яндекса»

    «Кликер» преобразует ссылки в формат clck.ru и создает QR-код, который можно сохранить как изображение. Сервис также дублирует короткую ссылку, прописывая её по буквам.

    vk.cc от «ВКонтакте»

    Чтобы воспользоваться vk.cc, необходимо авторизоваться через «ВКонтакте». Сервис позволяет сокращать ссылки, а также отслеживать статистику по ним: число переходов, уникальных посетителей и просмотров.

    Bitly

    Cокращать ссылки на Bitlу можно анонимно, но чтобы получить доступ к инструментам аналитики, придётся зарегистрироваться. Авторизованные пользователи также могут изменять ссылки — например, создавать собственные короткие имена.

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

    to.click

    Сервис to.click позволяет сокращать и редактировать ссылки и анализировать поступающий по ним трафик. Ссылками можно управлять пр помощи API, кроме того, to.click предлагает сокращать ссылки при помощи бота в Telegram.

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

    Droplr

    Droplr – это облачный сервис для обмена фото, видеофайлами и другими файлами. Платформа также позволяет сокращать ссылки — для этого нужно авторизоваться на сайте при помощи электронной почты.

    Ну как, зачем? Goo.gl такой удобный. Много есть не просит зачем его убивать( не понимаю(((

    urlog.ru юзайте, сейчас самая топовая сокращалка! Вот такие визитки с QR-Code генерирует автоматически, для соцсетей и других известных сайтов логотип меняется тоже, думаю для людей занимающихся бизнесом будет полезно!

    Удобный-то , он да, но в вк не проходит. А Глобус, укоротить не получается в вк. Что делать в такой ситуации, может кто-нить встречался с такой проблемой и решил?

    «Кликер» от «Яндекса»

    Оказывается при загрузке видео урезается звук и конвертируется в гиф 🙁

    Сюрпризы, сюрпризы . новые фичи добавляются и исчезают, и блога разработчиков vc.ru нету, чтобы о них прочитать 🙁

    Почему Яндекс не может сделать просто сервис . Почему он вечно такой не удобный и перегруженый. Так ещё с интерфейсом как 20-летней давности.

    Гуглы — козлы. Нахрена закрывать сервис?

    Активно распространяют вирусы и фишинговые страницы. Модерировать им лень. Зарабатывать на этом сложно — хотя могли бы при редиректе добавлять страницу с адресом куда человек собрался, предупреждением о небезопасности перехода, и показывать рекламу. Еще могли бы всю базу ссылок шерстить антивирусом нон-стоп — он у них есть, в почте работает ведь.
    Но им проще закрыть.

    А еще есть https://ylink.pro. С ботом в Telegram (https://t.me/ylinkpro_bot), умеющим работать в инлайн режиме, чатах, каналах и хранить картинки

    Из представленный самый полезный u.to, так как имеет меньше всего символов. Это важно, что сокращении текста сообщений, например, в телеграме (ограничения в 200 символах при медиа)

    Приятно, что наш сервис https://to.click попал в этот обзор. Могу ответить на вопросы и помочь с переездом если нужно.

    Sergey Boyarsky, jr.

    Две недели пользования вашим сервисом для переадресации на сайт регистрации на некоммерческий корпоративный ивент в google sites. Как результат: каждый день сервис по три-пять раз выпадает в ошибку и недоступен каждый раз по 10-20 минут. И как апогей — моя ссылка без предупреждения заблокирована, хотя она не нарушает ни одно из правил. Достучаться в поддержку просто нереально. Такой сервис отправляется в топку.

    Животных набежало. Как собаки Павлова — жмут кнопки ))))

    если нужно сокрашать ссылки для апп сторов и умные редиректы делать то еще есть https://onsto.re/

    куда лучше использовать Российский продукт https://utka.su/

    Еще хороший сервис сокращения ссылок https://ogo.gl/
    Есть статистика, QR-коды, можно поставить лимит на кол-во переходов ,а также есть возможность самому выбрать текст сокращенной ссылки

    https://vk-cc.ru пользуюсь для сокращения со своим доменом или https://vk.io, по функционалу как битли, только русское и бесплатное. Тоже можно свой домен подключить и тоже можно хитрые редиректы делать

    Thanks for a mention about Droplr guys!

    We are proud to be on your list! I think it’s good to say in Droplr you can customize your links (if you have a PRO account) and send the link from your own domain like yourdoma.in/1234 you can send share files, photos, texts or even links 🙂

    Best,
    Filip from Droplr

    Неплохие сервисы в списке, пользовался раньше кликером, но сейчас мне понравился другой сервис по сокращению ссылок, которым я пользуюсь уже на протяжении месяца urlog.ru, странно что его нет в списке,я нашел его у другого блогера в списке, не зря он стоял у него на первом месте. Очень хороший сервис, есть все инструменты для сокращения ссылок, будь то пароль на ссылку или графики переходов, чего стоит одна стоуровневая проверка, это значит что ваша короткая ссылка ни когда не совпадет с чей либо и самое главное что urlog бесплатный. Например ссылку на эту статью: https://vc.ru/flood/35599-7-servisov-dlya-sokrashcheniya-ssylok он сократит вот так: https://urlog.ru/u84ep3 легко запоминается и ничего лишнего! Еще понравилось копирование сгенерированный ссылки в один клик и оптимизированый под мобильные устройства интерфейс, очень выручает когда медленный интернет загружается сайт на ура, в общем рекомендую!

    0
    Неплохие сервисы в списке, пользовался раньше кликером, но сейчас мне понравился другой сервис по сокращению ссылок, которым я пользуюсь уже на протяжении месяца urlog.ru, странно что его нет в списке,я нашел его у другого блогера в списке, не зря он стоял у него на первом месте. Очень хороший сервис, есть все инструменты для сокращения ссылок, будь то пароль на ссылку или графики переходов, чего стоит одна стоуровневая проверка, это значит что ваша короткая ссылка ни когда не совпадет с чей либо и самое главное что urlog бесплатный. Например ссылку на эту статью: https://vc.ru/flood/35599-7-servisov-dlya-sokrashcheniya-ssylok он сократит вот так: https://urlog.ru/u84ep3 легко запоминается и ничего лишнего! Еще понравилось копирование сгенерированный ссылки в один клик и оптимизированый под мобильные устройства интерфейс, очень выручает когда медленный интернет загружается сайт на ура, в общем рекомендую! Что то тормозят комментарии!

    Wlinks.ru короткие ссылки с паролем

    https://ur-l.ru — очень хороший и удобный бесплатный сервис сокращения ссылок.
    Есть статистика переходов, произвольное название ссылки, QR-код, защита паролем, срок действия ссылки, геотаргетинг, панель управления и многое другое.

    А чего в списке нет https://urlog.ru вполне достойный сервис, всяким bitly и vk Мне нравится как он делает визитки с QR-code, вот например короткая ссылка на эту статью https://urlog.ru/u84ep3 и визитка на неё.

    битлу всем хорош, но довольно часто он почему-то баниться Роскомнадзором.

    А еще сможешь минуснуть? Ну, але-ап! ))))

    А можешь поставить еще 40 минусов? Ну, чтобы у тебя отлегло. А то тебя прямо трясет )))

    Docker для начинающего разработчика


    Docker стремительно ворвался в мир контейнеров и за пару лет из надстройки над LXC развился в систему запуска, окрестрирования, кластеризации, конфигурирования, поставки и создания контейнеров с программным обеспечением. Он так-же имеет простой интерфейс для контроля над ограничением ресурсов. Основой основ для докера служат linux namespaces, которые позволяют изолировать и виртуализировать ресурсы системы, такие как сеть, процессы, точки монтирования и пользователи. В итоге мы можем запустить любой процесс совершенно изолированно, как от самой системы так и от других контейнеров, в своем уникальном программном окружении, со своей сетью, деревом процессов, файловой системой и сетью. Все это дело работает исключительно поверх линукса, docker for windows, docker for osx — это велосипеды с линуксовской виртуалкой. Поэтому некоторые вещи работать там не будут, а некоторые ток с бубном.
    Имея опыт работы с джейлами во FreeBSD, zfs-зонами Solaris, openvz и lxc системами линукс можно с уверенностью заявить, что докер вылечил большинство болячек предшественников, и значительную часть головников админов/девопсов о том, как запустить перевел в плоскость, где запустить). Имея докерфайл, дженкинсфайл, вагрантфайл и анзибл с паппетом дев, опс, девопс теперь имеет в наличии everything as a code. Что позволяет ему воспроизвести с нуля весь стек разработки и поставки в любое время в любой среде.

    Звучит круто, с чего мне начать?

    Процесс установки бессмысленно описывать, так как разработчики докера слова “просто” и “понятно” понимают буквально, что в итоге выливается в хорошие доки и простые шаги установки. Здесь можно найти доки для любой популярной платформы.
    Итак, докер у нас есть и введя docker в консоли мы ужасаемся от списка команд вываленных на экран. Стоит отметить, что с версии 1.13 появился раздел Mangement Commands, куда со временем перетекут все команды, а они в свою очередь будут удалены. А пока например команды docker container run и docker run идентичны.
    Большинство опенсорсных проектов сейчас имеют докерфайлы и уже готовые докер-имейджи. Разработчику нет необходимости устанавливать на свою машину mysql/postgres/redis/mongo/apache/python/nodejs/php итд — все необходимые версии софта упакованы разрабами в официальне образы. Для примера запустим nginx:

    Данная команда скачает latest имейдж с офиц репо nginx на докерхаб, создаст и запустит контейнер с nginx(по сути docker run — это комбинация команд docker pull, docker create, docker start и docker attach). В соседней консоли наберем команду docker ps

    Здесь мы видим, что у нас запущен один контейнер с обазом nginx. И по сути от нашей команды docker run больше никакой пользы и нет. Чтобы убить контейнер нужно ввести команду docker kill . Чтобы увидеть помимо запущенных и потушенные контейнеры — можно набрать docker ps -a:

    Наигрались и удалили контейнер совсем.
    Немного добавим параметров в запуск контейнера:

    Из непонятных параметров я думаю тут -d и -p. Первый флаг запускает контейнер в бэкграунде, второй паблишит порт(форвардит порт из системы) в контейнер. Теперь перейдя по адресу http://localhost:8080 мы окажемся на приветственной страничке nginx. В систему можно прокидывать любой произвольный порт, но только на тот, что экспозится в контейнере, -p можно задать несколько раз, можно так-же задать диапазон. Команда ниже покажет stdout и stderr контейнера:

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

    Так мы открываем интерактивную псевдо-tty консоль( -ti ) а запускаем там bash. И можем установить необходимый софт, который будет доступен на время жизни контейнера:

    Чтобы контейнер с nginx стал еще полезнее, пусть он отдает нашу статику:

    Таким образом мы монтируем папку /static/content в контейнер с nginx. Аналогично можно примонтировать в контейнер кастомные конфиги в папку /etc/nginx контейнера. В качестве источника можно указать другой контейнер.
    Полный список команд докера и их параметров можно посмотреть тут.

    Как я уже писал выше, по дефолту docker качает latest таг имейджа, если необходимо указать конкретную версию, это делается через двоеточие например latest версия nginx на базе alpine-linux будет выглядеть как nginx:alpine. Доступные и поддерживаемые версии лучше всего смотреть на официальных страничках докерхаба и стора.

    Увлекательно, но мало!

    Попробуем разобрать более сложный вариант — мы разрабатываем тему для wordpress и нам необходимо его быстро развернуть у себя локально. Инсталлить пых как модуль апача или фпм, инсталлить мускуль, это все настраивать, а если несколько тем — носиться с вхостами, отдельными бд итд уныло и утомительно. Поэтому идем на офиц странички wordpress и mysql, изучаем, выбираем версии и вперед.
    Работать мы будем из корня проекта, тема наша лежит в папке themes/mytheme.
    Запускаем базу данных:

    По умолчанию пользователь будет root, а через переменную окружения мы задаем пароль
    Запускаем Вордпресс, коннектим его к бд и монтируем в контейнер нашу тему:

    По дефолту контейнеры друг друга не видят, здесь мы использовали параметр link, чтобы законнектить контейнер с Вордпрессом к контейнеру с бд. Помимо этого включается докеровский резолвер и ипка контейнера с базой данных будет резолвиться по имени db. Этот хостнейм мы используем в настройке Вордпресса через переменную окружения WORDPRESS_DB_HOST. Перейдя на http://localhost мы закончим установку и можем применить нашу тему.
    Как видим, две команды и Вордпресс готов. Однако и это можно улучшить — команда докера написала отличный скрипт, который очень полезен для разворачивания комплексных сервисов на рабочих станциях разработчиков.

    После простой инсталляции перейдем сразу к предыдущему примеру и перенесем его в docker-compose.yml. Данный файл описывает наши сервисы и контейнеры, параметры запуска итд. На текущий момент существует уже 3.1 версия формата. каждый ямл файл должен начинаться с версии. По умолчанию docker-compose ищет docker-compose.yml в текущей дире, через параметр -f можно указать любой другой файл или перечислить все файл, если их несколько.

    Касательно версий, то если грубо — version: “1” — это простое описание команд запуска докер контейнеров в ямл формате. В version: “2” добавилось понятие сервисов, теперь контейнеры можно скейлить, так-же добавилась секция с описанием вольюмов и сетей и их драйверов. По умолчанию, если сеть не задана, docker-compose при запуске создает новый бридж и коннектит все сервисы к нему, включает резолвер (резовлятся как сервисы, так и отдельные контейнеры). Не нужны линки для взаимосвязи между контейнерами. Version: “3” работает только с docker-engine 1.13+. Данная версия учла кривой опыт doker bundle и реализовала простой и прозрачный деплой в swarm-кластер, в 3.1 запилили поддержку docker secrets. Для сингл хоста за глаза второй версии.
    docker-compose.yml:

    Данный файл положим в корень проекта(как мы видим docker-compose понимает относительные пути, поэтому мы указали ./themes в описание вольюма с темой). Чтобы запустить наш Вордпресс достаточно набрать команду docker-compose up или docker-compose up -d чтобы запустить в бэкграунде:

    Данный файл удобно держать с проектом. Таким образом мы или кто-либо еще всегда смогут поднять проект(в нашем случае проект с темой Вордпресса) на любом компе с докером.
    Подчистим за собой:

    Напишем более сложный ямл, для Вордпреса docker-compose-staging.yml:

    В примере выше мы создали вольюм для базы данных db-mysql и примонтировали его в контейнер с мускулем в /var/lib/myql. Сделали мы это для того, чтобы при пересоздании, рестарте итд — данные сохранялись. Так-же создали две сети: внешняя wp-proxy для соединения сервисов nginx и wordpress и внутреннюю wp-db для коннекта сервиса водпресс с базой данных. Для сервиса Вордпресс помимо темы, мы создали два вольюма, для того чтобы заперсистить плагины и аплоад. Теперь при пересоздании контейнеров бд и Вордпресса все наши данные будут сохранятся, так как мы вынесли их из контейнеров.
    В качестве прокси мы заюзали имейдж jwilder/nginx-proxy, который слушает сокет докера, и если находит переменную окружения VIRTUAL_HOST — создает указанный виртуалхост у себя в конфигах с проксированием на контейнер, где прописана эта переменная. Если контейнер экспозит несколько портов, надо указать так-же и VIRTUAL_PORT, куда будет проксироваться трафик.

    Запустим наше творение:

    В /etc/hosts укажем

    При переходе в браузере по ссылке http://wp.local откроется привычный визард настроки вордпресса. Внутри контейнера nginx-proxy в конфиг /etc/nginx/conf.d/default автоматом добавится следующая запись:

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

    А секция upstream в nginx примет вид:

    Помимо этого, в пределах сети wp-proxy оба контейнера доступны по названию сервиса wp. А в версии 3 докер-композа мы можем провернуть тоже самое в swarm-кластере.

    В итоге без какого-либо напряга мы создали масштабируемый сервис на Вордпрессе.

    Убедил, хочу заиметь свой контейнер!

    Для начала сделаем шаг назад — а что такое контейнеры? Обычному человеку при слове контейнер на ум может придти 20и тонник. Это прочный объект, который выдерживает нагрузку во время хранения, погрузки и транспортировки и защищают содержимое, находящееся внутри. В голове так-же может возникнуть картинка с портовым доком, где стоят тысячи контейнеров в рядах, составленные друг на друга. Большая часть мерчанта поставляется в таких контейнерах: они прочны, стандартны, их легко хранить и транспортировать. Основная часть людей, задействованная в поставке не имеет представления что находится внутри, для поставки это не имеет значения. Идея софтварных контейнеров аналогична — это неизменные изолированные образы с ПО, функционал которых доступен чаще всего через вызовы api. Это современное решение для надежного запуска ПО (почти) в любом окружении, будь то комп разработчика, тестовые сервера или продакшн кластер. Не важно где — результат запуска всегда будет неизменным.
    Поскольку поведение предсказуемо и неизменно независимо от среды, то самый упоротый диалог на свете наконец уходит в небытие:

    QA: не работает n’ный функционал на проде.
    Dev: но у меня на компе все ок!

    В терминологии докер: контейнер — это запущенный образ. Что из себя представляет изнутри сам образ, советую прочитать эту статью. Если грубо, то докеровский имейдж — это стопка более мелких имеджей, каждый из которых содержит файлы, команды, результат их выполнения и другую мета-инфу. Потом драйвер overlay при запуске все это собирает в заданном порядке и из контейнера это выглядит как цельная единая система. Помимо этого, при старте контейнера поверх всего создается новый слой/имейдж. При удалении контейнера по сути только этот слой и удаляется со всеми изменениями произошедшими во время жизни контейнера, однако их можно “закоммитить” создав новый образ.
    Текстовым представлением докеровского образа является Dockerfile. При команде docker build этот файл считывается, каждая строка-команда запускает новый контейнер, а ее результат коммитится в новый слой/имейдж. Далее рассмотрим простой пример и все станет понятно. Для этого склонируем проект:

    Проект не мой, я просто его форкнул, немного подправил и добавил Dockerfile:

    Каждый Dockefile начинается с команды FROM, так мы объявляем, какой базовый имейдж мы будем использовать. Далее может быть указан MAINTAINER, это просто служебная инфа о том, кто во этом всем виноват. В моем случае за базовый имейдж я взял python:2.7-alpine. после чего идут команды RUN. По сути это инструкция, что нужно выполнить внутри имейджа и закоммитить в новый слой. Если с первой командой все более-менее понятно, то второй RUN выглядит мягко говоря по уродски, ее можно было бы переписать так:

    Однако, необходимо помнить, что каждое успешное завершение команды ведет к созданию нового слоя, который записывается поверх предыдущих. Соответственно мы установили пачку пакетов, в тмп склонировали проект, а после установки почистили /tmp и удалили ненужные пакеты. Последние два слоя пометят файлы как удаленные, но сами слои не удалят, а запишутся поверх. В итоге у нас и место не очистится, и файлов в контейнере не будет. Собрав первый Dockerfile мы получим имейдж размером 94Mb, собрав второй, работающий точно так-же — 261Mb. Соответственно при написании докерфайлов всегда следует держать баланс между читаемостью и экономией места, особенно для прода, и по возможности объединять в oneliners команды инсталляции, деинсталляции и удаления, чтобы все это выполнялось в рамках одного слоя.

    Помимо RUN есть еще команды COPY ADD CMD и другие. COPY копирует файлы из текущего контекста системы в имейдж по указанному пути. Следует помнить, что команда COPY /etc /etc не скопирует /etc/ системы в имейдж, корнем для команды будет директория, которая указана в контексте билда имейджа. Команда ADD аналогична COPY за тем исключением, что понимает урлы и архивы. CMD — команда, которую следует выполнить при запуске контейнера(ее можно определить/переопределить и при старте).

    Как уже писал выше, за основу моего имейджа был взят python:2.7-alpine. Это официальный имейдж питона версии 2.7 на базе легковесного дистрибутива linux alpine. В качестве сборки мелких имеджей alpine — лучший выбор, однако следует помнить, что за основу здесь взята сишная либа musl и пока не каждый софт скомпиллится и заработает в alpine.

    На проде мы используем debian, как базовый образ, несмотря на то, что весит он больше 120Mb против 4Mb у alpine. Это не проблема, т.к. этот слой копируется только один раз, а все остальные имейджи будут использовать локальную копию. Помимо этого, дебиан надежен и предсказуем, и по умолчанию в нем есть все необходимое.

    Но для мелких тулз alpine подходит лучше всего. Самый первый исходный образ — scratch. По сути не содержит ничего. Его можно использовать для гошных бинарников. однако следует не забывать, что необходимо скопировать туда корневые ссл сертификаты и необходимые либы, которые покажет ldd. Советую почитать так-же, что пишут сами докеровцы о докерфайлах. Так-же отличным примером различных техник служат официальные докерфайлы Вордпресс, мускуль, пхп, го, питон, редис итд.

    Чтобы собрать наш имейдж необходимо в директории проекта выполнить команду

    В качестве имени имейджа мы указали bamboo-build-tools (можно указать несколько), а в качестве контекста для команд COPY и ADD точкой текущую диру. По умолчанию docker build ищет Dockerfile, однако через -f можно указать любой другой файл, аналогично и с контекстом — можно указать любой другой путь.

    Еще один головняк для девелопера?

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

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

    Docker: практическое руководство для начинающих

    Перевод первой части статьи «Docker simplified: a hands-on guide for absolute beginners».

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

    В этом посте я постараюсь как можно более простым языком рассказать, что такое Docker.

    Итак, что такое Docker?

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

    Написан Docker на языке программирования Go, первая его версия была выпущена в 2013 году.

    В связи с богатством функционала, предлагаемого Docker, он широко применяется в ведущих мировых организациях и университетах (среди них – Visa, PayPal, Корнеллский университет и университет Индианы) для запуска и управления их приложениями.

    А теперь давайте разберемся, какая проблема стоит перед разработчиками и какое ее решение предлагает Docker

    Проблема

    Скажем, у вас есть три различных приложения на Python, которые вы планируете размещать на серверах (это могут быть физические или виртуальные машины).

    Каждое из этих приложений использует свою версию Python, а также отдельный, специфический набор библиотек и зависимостей.

    Поскольку мы не можем установить на одной машине разные версии Python, мы не можем и разместить на ней и все три приложения сразу.

    Решение

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

    Оба варианта позволят нам установить различные версии Python и пакеты зависимостей на каждой из этих машин.

    И при любом из этих вариантов расходы, связанные с приобретением и поддержкой «железа», будут довольно высокими.

    А теперь давайте рассмотрим вариант решения с помощью Docker и разберемся, почему оно более экономичное.

    Чтобы это понять, нужно вникнуть в то, как именно функционирует Docker.

    Как это работает

    Машину, на которой установлен и запущен Docker, обычно называют Docker Host или просто «хост».

    Чтобы развернуть приложение на хосте, на нем сначала создается логическая сущность для размещения этого приложения. В терминологии Docker эта логическая сущность называется контейнером (Container) или, если быть более точным, контейнером Docker (Docker Container).

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

    Таким образом, ядро операционной системы хоста разделяется между всеми контейнерами, запущенными на нем.

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

    Короче говоря, вместо виртуализации компонентов «железа», Docker виртуализирует операционную систему хоста, на котором он установлен и запущен.

    Преимущества и недостатки использования Docker

    Основные преимущества применения Docker

    • Множественные приложения с различными требованиями и зависимостями могут располагаться вместе на одном хосте, если у них одинаковые требования к операционной системе.
    • Оптимизированное хранилище. На одном хосте может размещаться очень много приложений, поскольку контейнеры обычно занимают всего несколько мегабайт и потребляют очень мало дискового пространства.
    • Надежность. В контейнере нет отдельной операционной системы. Поэтому он потребляет очень мало памяти по сравнению с виртуальной машиной, где устанавливается и запускается ОС. Благодаря этому также снижается до нескольких секунд время загрузки, в то время как виртуальной машине на загрузку нужна пара минут.
    • Снижение расходов. Docker менее требователен относительно «железа», на котором он запускается.

    Недостатки использования Docker

    • Приложения с разными требованиями к операционной системе не могут размещаться на одном хосте Docker. Допустим, у нас есть четыре разных приложения, три из которых запускаются в Linux, а одно – в Windows. При таком сценарии первые три могут размещаться на одном хосте Docker, а для одного, которое нуждается в Windows, потребуется другой хост.

    Основные компоненты Docker

    Движок Docker (Docker Engine) это один из его ключевых компонентов. Он отвечает за функционирование платформы Docker в целом. По своей сути это клиент-серверное приложение, состоящее из трех основных компонентов:

    Сервер запускает демон под названием dockerd (Docker Daemon), являющийся просто процессом. Он отвечает за создание и управление образами Docker, контейнерами, сетями томами платформы Docker.

    REST API определяет, каким образом приложения могут взаимодействовать с сервером и указывает им, как они должны работать.

    Клиент это ни что иное как интерфейс командной строки, позволяющий пользователям взаимодействовать с Docker при помощи команд.

    Терминология Docker

    Давайте пробежимся по терминам, связанным с Docker.

    Образы Docker (Docker Images) и контейнеры Docker (Docker Containers) это две важных вещи, с которыми вы будете постоянно сталкиваться, работая с Docker.

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

    А контейнер Docker это логическая сущность. Более конкретно – это запущенный экземпляр образа Docker.

    Что такое Docker Hub?

    Docker Hub это официальный онлайн-репозиторий, где вы можете найти все доступные для использования образы Docker.

    Docker Hub также позволяет нам хранить и при желании распространять наши собственные образы. Мы можем делать их публичными или приватными в зависимости от наших нужд.

    Пожалуйста, учтите, что при бесплатном использовании Docker Hub можно хранить приватно только один образ Docker. Если вам нужно больше, придется оформить платную подписку.

    Редакции Docker

    Docker доступен в двух редакциях:

    • Community Edition, CE (редакция сообщества)
    • Enterprise Edition, EE (корпоративная редакция)

    Community Edition подходит для отдельных разработчиков и маленьких команд. Эта редакция предоставляет ограниченный функционал по сравнению с Enterprise Edition.

    Enterprise Edition, в свою очередь, подходит для больших команд и для использования Docker в продакшен-среде.

    Enterprise Edition делится еще на три разных редакции:

    • Basic Edition
    • Standard Edition
    • Advanced Edition

    Установка Docker

    Прежде чем приступить к работе с Docker, давайте рассмотрим, как его устанавливать.

    Ниже даны ссылки на официальные руководства Docker по установке Community Edition. Они довольно простые, можете воспользоваться ими для установки Docker на вашу машину.

    Если вам лень устанавливать Docker или же у вас просто недостаточно свободных ресурсов на вашей машине для его установки, а поиграться хочется, – есть решение. Есть специальная онлайн-«песочница» – Play with Docker. Там пользователи могут попрактиковаться вводить команды, не устанавливая ничего на свою машину. Площадка проста в использовании и совершенно бесплатна.

    В следующей статье мы рассмотрим основные команды Docker, которые помогут вам начать работать с ним.

    Мастер Йода рекомендует:  Как слать письма PHP аттачами PHP
    Добавить комментарий