В комментариях к моей статье Docker: вредные советы было много просьб объяснить, чем так ужасен описанный в ней Dockerfile.
Краткое содержание предыдущей серии: два разработчика в жестком дедлайне составляют Dockerfile. В процессе к ним заходит Ops Игорь Иванович. Итоговый Dockerfile плох настолько, что ИИ оказывается на грани инфаркта.
Сейчас разберемся, что не так с этим Dockerfile.
Итак, прошла неделя.
Итак, начнём.
При внедрении DevOps-процесса в компании одним из возможных вариантов хранилища артефактов сборки может стать rpm-репозиторий. По существу — это просто веб-сервер, раздающий определённым образом организованное содержимое. Есть, конечно, коммерческие варианты maven-репозиториев, которые имеют плагины для поддержки rpm, но мы же не ищем лёгких путей?
Написать сервис, который будет принимать готовые rpm-пакеты по протоколу HTTP, парсить их метаданные, раскладывать файлы пакетов по каталогам в соответствии с внутренней структурой репозитория и обновлять метаданные репозитория после обработки очередного пакета. Что из этого получилось — описано под катом.
Доброе время суток! В данном посте я хочу рассказать как с помощью инструмента Sparrow лёгко и просто писать собственные обёртки к существующим скриптам и утилитам, а так же зачем вам это может понадобиться.
Про использование Docker и Docker-compose последнее время написано очень много, например рекомендую недавнюю статью на Хабре, если вы до сих пор не прониклись. Это действительно очень удобно, а в связке в ansible особенно. И я его использую везде. От разработки, до автоматического интеграционного тестирования на CI. Про использование в тестировании, тоже писали. Это здорово и удобно. Однако, для локальной разработки, для траблешутинга данных "как в продакшене" или тестирование производительности, на "объёмах близких в продакшену", хочется иметь под рукой образ, содержащий базу, "как в продакшене"!
Соответственно, хочется, чтобы каждый разработчик, приступая к работе над проектом, мог запустить его одной командой, например:
./gradlew dockerRunи приложение поднялось бы сразу со всеми необходимыми связанными контейнерами? А главное чтобы в нём уже были бы данные для большинства кейсов разработки и багфиксинга, стандартные пользователи и большинство работающих сервисов, над которыми сразу можно было бы приступить работать, не тратя времени на экспорт-импорт каких-то там образов или демоданных!
Как приятный бонус, ну разве не здорово иметь базу данных в несколько гигабайт и возможность откатиться к её исходному (или любому другому коммиту) состоянию в течении пары секунд?
Разумеется мы поговорим о написании Dockerfile для такого образа с данными, и некоторых подводных камнях этого процесса.
Sparrow — система многоцелевых сценариев, спроектированная для разработки и запуска разнообразных скриптов автоматизации. В зависимости от требуемых задач — это может быть развертывание и настройка приложений, мониторинг или тестирование северной инфраструктуры или же решение других вопросов — другими словами — выполнение любых скриптов в автоматическом режиме.
До недавнего времени запуск подобных сценариев был ограничен консольным клиентом ( sparrow или sparrowdo ), сегодня я бы хотел презентовать пилотный проект по автоматической установке и запуску sparrow сценариев на удаленных серверах посредством централизованного web сервиса — SparrowUP.
На хабре подозрительно мало информации про Open Build Service (далее OBS) и прочие платформы.
А про свежесть имеющегося и говорить не хочется.
Недавно был релиз версии 2.7, пришли долгожданные изменения.
Но, для истории, хочу немного рассказать об одном варианте использования 2.6 (релиз — февраль 2015 года).
Пример для материала навеян недавней потребностью.
Итак, собирем php-ffmpeg на базе ffmpeg 3.0 для Centos (7, и даже 6*!).