Alpine linux libpq dev
Note: this project is no longer maintained.
An attempt at a «buildpack-deps»-like Docker image with Alpine Linux
This repo contains a set of images similar to the official buildpack-deps images.
| Tag | Base image | Description |
|---|---|---|
| curl | alpine:3.x | Alpine with curl and wget |
| scm | :curl | :curl with source control management (SCM) tools |
| latest | :scm | :scm with build tools and development libraries |
- A best effort was made to find equivalent Alpine packages for the Debian packages in the official buildpack-deps. The packages may not always be 100% equivalent.
- The code you’re compiling in buildpack-deps could make assumptions about the host that are not necessarily true for Alpine Linux. For example:
- That the standard Unix tools are the GNU implementations
- That the standard C library is glibc
- That the paths to development files are the Debian paths
- The default/ latest tag for this image is not significantly smaller than the Debian/Ubuntu-based buildpack-deps images
, although it is roughly the same size (
660MB uncompressed). The reason for this is that the Alpine development libraries for PostgreSQL and MySQL are significantly bigger than the Debian ones.
If you are hoping to make a small «buildpack-deps»-based Docker image, you’re probably doing Docker images wrong.
The packages in the curl and scm variants mostly have the same names in Alpine Linux as they do in the Debian/Ubuntu source. The translation of packages for the latest image is a bit more complicated, though. The packages used are listed below.
| buildpack-deps | alpine-buildpack-deps |
|---|---|
| ca-certificates | ca-certificates |
| curl | curl |
| dirmngr | gnupg |
| gnupg | gnupg |
| netbase | alpine-baselayout * |
| wget | busybox |
Additionally, we install the tar package in the curl image. This installs the GNU version of tar, which has more features than the BusyBox tar provided with Alpine Linux. In particular, the —strip-components option only available in GNU tar is commonly used in the Docker official images when extracting source code from tarballs.
*This package is one of the base packages of Alpine Linux. It includes most of the netbase files including /etc/protocols and /etc/services .
| buildpack-deps | alpine-buildpack-deps |
|---|---|
| git | git |
| mercurial | mercurial |
| openssh-client | openssh-client |
| procps | procps |
| subversion | subversion |
| buildpack-deps | alpine-buildpack-deps |
|---|---|
| autoconf | autoconf |
| automake | automake |
| bzip2 | bzip2 |
| dpkg-dev | dpkg , dpkg-dev |
| file | file |
| g++ | g++ |
| gcc | gcc |
| imagemagick | imagemagick-dev |
| libbz2-dev | bzip2-dev |
| libc6-dev | libc-dev , linux-headers |
| libcurl4-openssl-dev | curl-dev |
| libdb-dev | db-dev |
| libevent-dev | libevent-dev |
| libffi-dev | libffi-dev |
| libgdbm-dev | gdbm-dev |
| libgeoip-dev | geoip-dev |
| libglib2.0-dev | glib-dev |
| libjpeg-dev | jpeg-dev |
| libkrb5-dev | krb5-dev |
| liblzma-dev | xz-dev |
| libmagickcore-dev | imagemagick-dev |
| libmagickwand-dev | imagemagick-dev |
| libmysqlclient-dev | mariadb-dev * |
| libncurses5-dev | ncurses-dev |
| libncursesw5-dev | ncurses-dev |
| libpng-dev | libpng-dev |
| libpq-dev | postgresql-dev * |
| libreadline-dev | readline-dev |
| libsqlite3-dev | sqlite-dev |
| libssl-dev | openssl-dev /( libressl-dev )** |
| libtool | libtool |
| libwebp-dev | libwebp-dev |
| libxml2-dev | libxml2-dev |
| libxslt-dev | libxslt-dev |
| libyaml-dev | yaml-dev |
| make | make |
| patch | patch |
| unzip | busybox |
| xz-utils | xz |
| zlib1g-dev | zlib-dev |
*Alpine Linux doesn’t have development packages for MySQL or PostgreSQL that include only the headers/libraries necessary for client-side libraries. These Alpine packages are quite large because they include server headers/libraries as well. **Alpine Linux between versions 3.5 and 3.8 used LibreSSL. For version 3.9, they switched back to OpenSSL.
About
An attempt at a «buildpack-deps»-like Docker image with Alpine Linux
Источник
Running glibc programs
If you want to run glibc programs in Alpine Linux, there are a few ways of doing so. You could install glibc as additional to musl (you would have to do this manually), or you could do it the easy way and use either Flatpak (the easiest) or a chroot.
Because there are different use cases, this is just a slight overview about what’s possible and what’s intelligent.
Contents
Your options
gcompat
gcompat is the go-to compatibility layer for Alpine users.
After that you run your binaries as normal.
Flatpak
Flatpak is by far the easiest method of running any graphical glibc program on Alpine. Firstly install it.
Then you can run any Flatpak application:
It is recommended to enable Flathub using it’s instructions here, as most glibc programs you might need will be packaged there.
You can then install applications from it, for example:
Chroot
Gentoo Linux
Select a stage3 from here and portage latest from here at gentoo/snapshots/portage-latest.tar.xz.
Enter the chroot:
And voilà, you have your working Gentoo chroot!
You can now take a look at Gentoo’s Handbook to find out how you can configure and install your system, or simply extract/copy the program you need to run in your chroot enviroment and execute it.
Here is a wrapper script that is similar to arch-chroot when you frequently reuse this chroot:
Also, create an account with the same user name as host current user to the chroot or make changes to the userspec option to chroot line.
Contents of gentoo-chroot.sh
Do at chmod +x gentoo-chroot.sh to get it to work.
Arch Linux
Either use pacstrap (included with the arch-install-scripts package) or an Arch bootstrap image:
Once that is done, update the system and install the desired package(s) (denoted by «foo» in this example):
Debian
Use the provided debootstrap package to create the Debian chroot. —arch is optional, depending of your needs.
On the linux-grsec kernel, you will need to relax chroot limitations:
You can now use apt-get to install needed packages.
Источник
Зачем забивать гвозди микроскопом, если есть Alpine Linux?
По зову сердца и работе в Digital Design в качестве системного инженера, мне часто приходится сталкиваться с переусложненными программными продуктами и архитектурными конструкциями. Это вызывает страстное желание минимизации и упрощения всего, что попадается под руку, и приводит к восторгу от человеческих решений, просто делающих свою работу , без регистрации и смс .
Так я и познакомился с Alpine Linux.
Этот дистрибутив может вам понравиться по следующим причинам:
- Если вы любите минимализм и инструменты, ориентированные на выполнение поставленной задачи без лишних свистелок и украшений;
- Если вы заметили, что имеющиеся «мэйнстримные» дистрибутивы немного (?) раздуты и избыточны;
- Если вы захотели решить имеющуюся задачу простым способом.
Под «мэйнстримом» я подразумеваю тройку CentOS — Debian — Ubuntu (конечно же, ими мир не заканчивается), да простят меня все верующие в эти замечательные дистрибутивы. При их использовании, периодически, на границе восприятия, возникает колкая мысль – «а может быть можно проще?».
Оно нам действительно надо?
$ holywar mode disable
Неужели для решения вашей небольшой задачи требуется все это:
Замечательная systemd. Система инициализации (уже не совсем), которая может произвести впечатление системы управления шаттлом?
Подсистема журналирования / аудита, построенная на связке вроде journald → rsyslogd + auditd?
Можно догадываться, почему это сделано именно так, но действительно ли для моей простой задачи требуется такая цепочка?
Дублирование функциональности периодического выполнения задач как в systemd, так и в crond?
Сосуществование нескольких подсистем управления сетью в разных сочетаниях: классический networking / networkd / NetworkManager?
Сервисы вида tuned и firewalld?
Локальный почтовый сервис. Вы точно будете его использовать?
Раз уж мы вспомнили про минимализм, можно очень грубо сравнить наши дистрибутивы-лидеры в их минимальном варианте установки:
- Лидером избыточности по дисковому пространству и числу пакетов оказывается Ubuntu 18.04 (2,8 ГБ дискового пространства, 342 пакета, 31 активный сервис systemd, 15 процессов при входе). Семейство systemd тут представлено в максимальном объеме — systemd, networkd, timesyncd, resolved, logind, есть dbus.
- CentOS 7.5.1804 проигрывает по диску и числу пакетов, но лидер по вероятно-избыточным сервисам (1.1 ГБ дискового пространства, 299 пакетов, 34 активных сервиса systemd, 19 процессов при входе, среди которых — NetworkManager, firewalld, tuned, postfix, polkitd, auditd, journald + rsyslogd, dbus).
- Debian 9.4.0 пытались сильно не надувать: 940 МБ, 334 пакета, 25 активных сервисов systemd, 14 процессов при входе. Само собой, тут тоже есть systemd (а также journald, timesyncd и сопутствующий dbus), но без особого фанатизма в части управления сетью.
holywar: cannot change mode to ‘disable’: Permission denied
Хочется странного
От части перечисленного выше можно (попробовать) избавиться вручную, но вдруг все уже придумано за нас? В идеале, от дистрибутива серверной операционной системы общего назначения хочется видеть:
- Как ни странно, загрузчик, который дотянет нас до ядра;
- Само ядро ОС (в рассматриваемом случае — linux);
- Система инициализации, которую ядро запустит по готовности. Желательно, по простоте недалеко ушедшая от топора;
- Минимальный набор процессов, который запустит система инициализации. Ну например:
- Окончательная инициализация устройств и определение дополнительных параметров ядра;
- Обеспечение журналирования (можно с текстовыми журналами? Ну пожалуйста);
- Конфигурация сети (хорошо бы, с меньшим числом управляющих прослоек);
- Синхронизация времени (ntpd / chronyd);
- Несколько локальных консолей;
- Опционально — периодическое выполнение задач (сrond);
- Опционально — удаленный доступ к системе (sshd);
- Хорошо бы еще сохранять и восстанавливать конфигурацию межсетевого экрана.
И на этом почти все, остальное — дело менеджера пакетов. Меньше исполняемого кода и конфигурации – меньше багов, меньше багов – меньше багов. А система все также запущена и доступна по сети. Идея выглядит неплохо, теперь посмотрим, насколько близок к ней дистрибутив Alpine Linux.
Про Alpine
Чем может очаровать Alpine, особенно после CentOS? Отчаянным минимализмом!
Ну и, конечно, отсутствием необходимости сертификации «Linux Systemd Certified Voldemort».
Что сделали авторы:
- Понизили число используемых базовых компонентов;
- Выбрали модули поменьше и попрозрачнее;
- Упростили процесс конфигурирования системы.
- Чрезвычайно лаконичный процесс установки с использованием консольной утилиты setup-alpine;
- В качестве загрузчика взят extlinux из состава проекта syslinux;
- Небольшой инструмент сборки mkinitfs для создания временной файловой системы, используемой при загрузке;
- Система инициализации openrc с определением зависимостей между сервисами, уровнями запуска и щепоткой скриптования;
- Замена стандартной библиотеки GNU libc на более легковесную musl libc;
- Вместо пакета GNU coreutils большинство стандартных системных утилит в несколько урезанном исполнении входят в состав пакета busybox, который может быть Вам знаком по встраиваемым решениям;
- По умолчанию используется командный интерпретатор ash в составе busybox. Само собой, никто не мешает при необходимости поставить bash , ну и systemd ;
- Собственный пакетный менеджер apk и собственная инфраструктура распространения пакетов.
Кроме того, авторы реализовали ряд мер, ориентированных на повышение уровня защищенности базовой системы:
- Применили патчи ядра grsecurity/PaX (про их эффективность мнения расходятся, но все же); Уже нет, спасибо коллеге из комментариев. Как раз 26 июня вышла версия 3.8.0.
- Собрали пакеты с использованием режимов, снижающих вероятность эксплуатации ряда возможных уязвимостей.
В итоге мы получаем систему, снабженную рядом дополнительных механизмов защиты, позволяющую решить имеющуюся задачу и занимающую около 130 МБ. В запущенной системе установлен 41 пакет и выполняется 13 пользовательских процессов, можно стучаться по ssh.
И больше ничего. Осталось добавить то, что нужно вам (да и iptables с возможностью восстановления конфигурации при старте поставьте).
Приоткроем крышку
Обратите внимание – Alpine может пригодиться как учебная площадка при ознакомлении с ОС Linux! Увидеть логику работы компонентов субъективно проще, чем пытаться охватить сходу CentOS или Ubuntu:
- Загрузчик нашей установленной системы прост, его конфигурация влезает в 12 строк:
- Да и в /boot не слишком многолюдно:
- А вот и запущенный загрузчик без модных обоев:
- Ядро загружается, подхватывает initramfs, отрабатывает собственные шаги инициализации и вызывает команду init (которая, на самом деле, тоже идет в составе busybox). Init использует файл /etc/inittab:
- И тут в явном виде прописано, что нужно запустить для инициализации системы:
- Запустить 6 процессов getty, ожидающих на 6 виртуальных консолях локального входа пользователя.
- Запустить систему инициализации openrc для поочередного достижения требуемых уровней инициализации (openrc использует не классические уровни инициализации 0-6, а собственные уровни/группы sysinit — boot — default).
Далее состояние системы зависит от конфигурации openrc, а именно:
- Переменных, заданных в файлах каталога /etc/conf.d;
- Скриптов запуска, находящихся в каталоге /etc/init.d;
- Привязки скриптов запуска к «группам инициализации»:
Осталось прочитать скрипты запуска и обработать их с учетом уровней запуска и зависимостей.
Можем на примере syslog (/etc/init.d/syslog) посмотреть, как выглядит скрипт запуска openrc.
Как видите, это не всегда эти ваши нелюбимые «портянки»:
Переменные, используемые при выполнении скрипта, определяются в соответствующем файле /etc/conf.d/syslog. В нашем случае, в файле определена переменная SYSLOGD_OPTS=»-Z».
Обратите внимание — в скрипте декларативно определены зависимости данного сервиса.
Openrc честно перебирает в заданном порядке скрипты запуска, достигает уровня «default» — и вот она, рабочая система!
Демоны под крышкой
Что же именно скрывается под скриптами запуска openrc? Как ни странно — набор задач и демонов, перечисленных ниже.
Сначала, на уровне sysinit:
- dmesg — выставляется уровень журналирования для сообщений от ядра;
- devfs — монтируется и настраивается /dev;
- mdev — запускается менеджер устройств;
- hwdrivers — загружаются модули устройств на основе информации из /sys и /dev;
Следующим идет уровень boot:
- modules — загружаются модули ядра, перечень которых определен в /etc/modules;
- hwclock — настраиваются аппаратные часы реального времени;
- sysctl — задаются параметры ядра, определенные нами в /etc/sysctl.conf;
- swap — подключается swap-раздел;
- bootmisc — очищаются временные каталоги;
- urandom — настраивается генератор случайных чисел;
- keymaps — инициализируется раскладка клавиатуры;
- hostname — задается имя машины, которое определено в /etc/hostname;
- networking — поиск и инициализация интерфейсов с использованием информации из /etc/network/interfaces;
- syslog — запускается демон журналирования из состава busybox;
И наконец, уровень default:
- chrony — запускается NTP-сервис;
- crond — запускается сервис выполнения задач по расписанию;
- acpid — запускается сервис отслеживания событий питания;
- sshd — запускается сервис удаленного доступа.
Ура, после выполнения этих шагов система готова к работе! Не забудем и про зависимости от перечисленных выше сервисов, которые были заданы в init.d файлах:
- sysfs — монтирование /sys;
- fsck — проверка и исправление файловых систем;
- root — монтирование корневой системы на запись/чтение;
- localmount — монтирование всех файловых систем, перечисленных в /etc/fstab;
- klogd — журналирование событий ядра.
Открываем одну из локальных консолей, где нас поджидает getty, вводим логин, после чего передаем пароль процессу login и получаем доступ к запущенному командному интерпретатору ash (при запуске которого выполняется содержимое файлов /etc/profile, /etc/profile.d/* и
/.profile для подготовки пользовательского окружения).
Ура, никаких дополнительных сущностей (несомненно, полезных в ряде случаев, вроде PAM) — а мы в системе!
Осталось воспользоваться пакетным менеджером apk, и поискать нужные нам для нашей задачи пакеты. (Есть ли они там? Можно оценить это через веб-портал).
А еще
Дистрибутив Alpine не идеален, но его лаконичность меня действительно впечатлила, особенно в роли контейнера (всего 6 процессов — init, 4*getty, syslogd). Для меня он выглядит так, как должна выглядеть минимальная серверная операционная система (прости меня, CentOS!).
Кроме того, он вполне подходит на роль учебной площадки, позволяющей увидеть, из чего состоит современный дистрибутив, не погружаясь сразу в пучину whateverd-сервисов и многократного дублирования функциональности в великолепно-многоуровнево-конфигурируемых-средствах на все случаи жизни.
Источник
