Gartner пишет, что через два года половина организаций мира будут использовать контейнерные технологии. Рассказываем, зачем они нужны.
3446 просмотров
Фото: John Jones (Flickr, CC BY)
Пара слов о виртуализации
Виртуализация — это разбиение аппаратного сервера на несколько виртуальных машин (ВМ). В результате вычислительные мощности распределяются между несколькими «пользователями».
Если говорить простыми словами, то виртуализация напоминает скоростной поезд , в котором едет сразу множество пассажиров. Они фактически делят между собой затраты на топливо и обслуживание транспорта, пользуются им по необходимости и экономят место на дороге (по сравнению с ситуацией, когда каждый вместо поезда выбирает собственный автомобиль).
Виртуализацией управляет программный компонент, называемый гипервизором. Он абстрагирует ВМ от аппаратного обеспечения, поэтому пользовательское приложение не знает, что работает в виртуальной среде.
Отсюда вытекает главное достоинство виртуализации: виртуальную машину можно без изменений переносить с одного сервера на другой вместе с операционной системой и приложениями.
ТОП Приложения для Android из F-Droid на каждый день
Как работают контейнеры
В случае с контейнерами на отдельные компоненты разбивается не «железо», а операционная система. Контейнеры — это изолированная среда для приложения, в которой содержится все необходимое для его работы, например, программные библиотеки, файлы и метаданные.
Можно провести аналогию с морскими контейнерами, с помощью которых на кораблях, фурах или поездах перевозят отдельные грузы. Программные контейнеры — это модули с кодом, выполняющим специфическую задачу .
Фото: Bernard Spragg. NZ (Flickr, PD)
Так как в контейнер помещается лишь одно приложение или функция, он весит намного меньше образа виртуальной машины и создается (запускается) быстрее. По этой причине их использует, к примеру, Spotify.
Контейнеры в инфраструктуре этого сервиса отвечают за добавление музыкальных композиций в плейлисты. Каждый контейнер-сервис при обращении к дата-центру компании выполняет одну задачу.
Первый узнает имя исполнителя, второй — скачивает обложку альбома, третий — текст песни и так далее. Такое «разделение обязанностей» помогает сервису обслуживать 70 млн пользователей. При этом все контейнеры изолированы друг от друга. Из-за своих небольших размеров они требуют меньше памяти и процессорной мощности, чем виртуальные машины. Они способны снизить нагрузку на серверы на 20–80%, по сравнению с ВМ.
Помимо Spotify контейнеры для разработки своих сервисов используют такие компании, как Yelp, Airbnb, Google, Microsoft, Lyft, eBay, PayPal и многие другие.
Что такое системы управления контейнерами
Система управления контейнерами (система оркестровки) — это веб-панель администрирования, которая руководит работой контейнеров. Примером может быть открытая платформа Kubernetes , разработанная Google.
Есть и другие решения — Docker, Rancher, OpenShift и так далее.
NVIDIA Container нагружает систему! ✅ Что это такое и как отключить?
Они нужны для гибкого масштабирования виртуальной инфраструктуры. Эти системы управляют «расписанием» (говорят, когда запускать тот или иной сервис) и распределяют нагрузку на серверы, чтобы вычислительные ресурсы расходовались равномерно.
По сути системы оркестровки, например, все тот же Kubernetes, — это ланч-бокс трансформер , который хранит всю «еду» в одном месте, но предоставляет каждому «блюду» свой независимый отсек. Еду можно доставать, менять и складывать обратно, не влияя на остальное содержимое.
Фото: Melissa (Flickr, CC BY)
Во время работы Kubernetes объединяет серверы в так называемый кластер — общую сеть, где «машины» могут взаимодействовать друг с другом. Один сервер выступает в роли «мозга» системы и управляет остальными «машинами» (их еще называют узлами). Узлы, получая инструкции от главного сервера, создают, удаляют и перемещают контейнеры.
Достоинством систем управления контейнерами является то, что вся эта «внутренняя кухня» скрыта от системного администратора или разработчика. Их задача — просто размещать контейнеры, а все остальное Kubernetes делает самостоятельно.
Но ряд особенностей работы таких систем все же приходится учитывать. Хотя контейнеры изолированы и не могут вмешиваться в работу друг друга, они делят между собой операционную систему. Поэтому важно убедиться, что код контейнерных приложений не мешает её работе.
Еще одной сложностью является безопасность таких систем. Один сервис может содержать множество контейнерных приложений, что создает больше «слабых точек», которыми могут воспользоваться злоумышленники. Шанс столкнуться с уязвимостью будет меньше, если у ОС и контейнеров будет только необходимый набор инструментов.
Настроить среду Kubernetes и организовать работу с контейнерами можно самостоятельно с нуля — для этого на GitHub, где лежит исходный код проекта, предоставлены все инструкции.
Другой вариант — воспользоваться облачными сервисами (например, «Контейнеры Kubernetes» от Mail.Ru), которые автоматизируют процесс установки Kubernetes и дают оперативно менять размеры кластеров, если трафик на сайте резко вырос. В этом случае все настраивают эксперты с большим опытом работы с Kubernetes на крупных проектах.
Что запомнить
- Контейнеры работают на уровне виртуализации операционной системы, а не «железа». Они изолированы друг от друга.
- Для работы с контейнерами есть системы вроде Kubernetes. Они определяют, когда запускать сервисы и делят нагрузку на серверы, чтобы вычислительные ресурсы расходовались равномерно.
- Контейнеры, их системы оркестровки и операционные системы нужно регулярно обновлять. Это простое действие значительно снижает риск взлома инфраструктуры.
- Настроить среду Kubernetes можно самостоятельно, а можно передать эту задачу облачному сервису, специалисты которого настроят все системы и будут регулярно их обновлять.
Другие наши заметки в блоге Mail.Ru Cloud Solutions:
- «Виртуальная инфраструктура: историческая ретроспектива»
- «Как управленцу разобраться с IT»
Наши подборки книг на vc:
- «Что почитать про облако: 10 книг для админов и IT-руководителей»
- «Мобильная разработка в облаке: что выбрать из книг»
Источник: vc.ru
Как и зачем собирать Android приложение в docker контейнере
Я — Владимир, меня зовут девопс. Говорят, что девопс — это болезнь и я это вам сегодня докажу.
Ответа на вопрос «зачем?» вы тут не найдете, это кликбейт, я и сам не знаю. Все происходящее мотивируется девизом «бикоз ай кен».
Если без шуток, то можно прогонять процесс сборки, создавать изолированные тест-кейсы, прогонять через автотесты, SonarQube и прочие SAST-ы
Итак. Дано. Один безумный девопс, один несчастный андроид-разработчик, собирающий апк локально. Ситуация, увы, распространенная.
Часть 1. Dockerfile. Как собрать
Как решаем. Пишем Dockerfile для дела и Jenkinsfile для понтов, сегодня речь только про Dockerfile.
Для успешного процесса нужно смазать вытащить из разработчика окружение, в котором вся эта радость собирается. Нас интересует версии gradle, jdk, android sdk
При выборе образа обратите внимание на версию gradle и java, gradle имеет debian корни, так что apt-get java на случай, если версии нет готовой. Создаем в корне репы Dockerfile и начинаем его заполнять:
Сразу проверяем, сходятся ли версии gradle и java
FROM gradle:6.1.1-jdk11 RUN java -version RUN gradle -v
т..к. Dockerfile лежит в корне репозитория, копируем содержимое в контейнер
RUN mkdir /opt/project COPY . /opt/project WORKDIR /opt/project
Два из трех есть — gradle и jdk установлены, ставим androidsdk.
Есть один нюанс. Для andriodsdk нужно вытащить архивчик с оным. Можно скурлить последнюю версию, а можно ручками смотреть тут.
Как девопс — я бы не хотел возвращаться к обновлению окружения руками, однако могут быть неприятные сюрпризы с новыми версиями androidsdk. Да и не всегда есть нужда в использовании latest. Так что просто укажем имя архива в переменной
ARG ANDROID_SDK_VERSION=8092744 ENV ANDROID_SDK_ROOT /opt/android-sdk
Скачиваем архив, распаковываем, чистим мусор
RUN mkdir -p $/cmdline-tools wget https://dl.google.com/android/repository/commandlinetools-linux-$_latest.zip unzip *tools*linux*.zip -d $/cmdline-tools mv $/cmdline-tools/cmdline-tools $/cmdline-tools/tools rm *tools*linux*.zip
То чувство, когда не успевал начать, а уже почти все готово.
Указываем PATH для androidsdk, куда полезет gradle
ENV PATH $:$/cmdline-tools/latest/bin:$/cmdline-tools/tools/bin:$/platform-tools:$/emulator
Обратите внимание на вторую строчку, где отдельно указаны пакеты androidsdk
В ранних версиях было достаточно установить androidsdk, сейчас же нужно отдельно ставить пакетыплатформысамоварыблудниц. Никто не мешает поставить сразу весь фарш, нооо.
Но чувство прекрасного говорит, что надо только то, что надо. Как определить какие пакеты собсна нужны? об этом ниже про нюансы
RUN yes | sdkmanager —licenses sdkmanager «platforms;android-29» «platforms;android-30» «platforms;android-31» «build-tools;29.0.2» cd /opt/project
Ну и последнее, творим магию
RUN gradle build
Целиком прекрасный Dockerfile
FROM gradle:6.1.1-jdk11 RUN mkdir /opt/project COPY . /opt/project WORKDIR /opt/project ARG ANDROID_SDK_VERSION=8092744 ENV ANDROID_SDK_ROOT /opt/android-sdk RUN mkdir -p $/cmdline-tools wget https://dl.google.com/android/repository/commandlinetools-linux-$_latest.zip unzip *tools*linux*.zip -d $/cmdline-tools mv $/cmdline-tools/cmdline-tools $/cmdline-tools/tools rm *tools*linux*.zip ENV PATH $:$/cmdline-tools/latest/bin:$/cmdline-tools/tools/bin:$/platform-tools:$/emulator RUN yes | sdkmanager —licenses sdkmanager «platforms;android-29» «platforms;android-30» «platforms;android-31» «build-tools;29.0.2» cd /opt/project RUN gradle build
Теперь про нюансы.
- 1. Как определить пакеты sdkmanager, необходимые к установке?
Можно посмотреть в студииспросить разраба. скорее всего будет уйма ненужного, так что вариант корнями ведущий в беспощадный ру-девелоп.
Можно присобачить юзера и volume в Dockerfile, самое очевидное.
Но на мой взгляд есть изящное решение в виде Jenkinsfile, т.к. он чуть более, чем полностью состоит из sh, можно делать то же самое, но руками:
docker build . -t build_apk docker run -d build_apk sleep infinity docker cp build_apk:/path/to/apk/in/docker/container/*.apk /path/to/home/dir docker stop build_apk docker rm build_apk
Кто то скажет «фу, костыль» и будет прав. Но это решение не претендует на истину в последней инстанции. Это простой и легкий в освоении вариант, который решает тактическую задачу
-
3. Что делать, если мы за прокси?
RUN mkdir -p $/cmdline-tools wget https://dl.google.com/android/repository/commandlinetools-linux-$_latest.zip —no-check-certificate unzip *tools*linux*.zip -d $/cmdline-tools mv $/cmdline-tools/cmdline-tools $/cmdline-tools/tools rm *tools*linux*.zip RUN yes | sdkmanager —licenses —proxy=http —proxy_host= —proxy_port= sdkmanager —proxy=http —proxy_host= —proxy_port= cd /opt/project
Не забываем прописать прокси в gradle.properies
systemProp.http.proxyHost= systemProp.http.proxyPort= systemProp.https.proxyHost= systemProp.https.proxyPort= #сходу бонус #чтобы сборка не обжирались и не падала с ошибкой «плак плак, хатю память» #выставим ограничение org.gradle.jvmargs=-Xmx2048m -Dkotlin.daemon.jvm.options=»-Xmx2048M» -XX:MaxPermSize=4096m
Если тянем с либы корпоративного репо — то и не забываем указать его же в build.gradle в двух местах!!
repositories < mavenCentral < url «https://corp.repo.example.ru/repository/maven-central/» >jcenter < url «https://corp.repo.example.ru/repository/jcenter/» >google < url «https://corp.repo.example.ru/repository/dl.google.com-android/» >> allprojects < repositories < mavenCentral < url «https://corp.repo.example.ru/repository/maven-central/» >jcenter < url «https://corp.repo.example.ru/repository/jcenter/» >google < url «https://corp.repo.example.ru/repository/dl.google.com-android/» >> >
P.S. Интрига
Мы ж тут про девопс, а потому мы хотим смузи и женщин автоматизацию.а потому хотим, чтобы после коммита в репу запускалась сборка и итоговая апк вываливалась в какой-никакой общий доступ.Как это сделать красиво — в следующей статье) про простейший nginx и JenkinsТам будет про вывалить версию в версию. Короче, интрига.
- Разработка под Android
- DevOps
Источник: habr.com