Сначала немного фона. Я разработчик программного обеспечения (в последнее время в Ruby и немного Java, ранее в Python, C # и PHP ; да, я немного обошелся), но потратил достаточно времени, чтобы заботиться о производственном оборудовании (в основном, Debian, Solaris и недавно немного RHEL ) чтобы почувствовать работу сисадмина. У меня даже есть друзья, которые являются системными администраторами. Я в основном использую блестящий ноутбук Apple для своей работы по разработке, но на самом деле я выполняю весь код на виртуальных машинах Linux. Цель этого поста — преодолеть разрыв, а не начать пламенную войну за конкретные инструменты.
Я пишу это частично, чтобы адресовать твит, который я сделал, чтобы задним числом понадобилось более 140 символов. На самом деле несколько моих недавних твитов были на одну и ту же тему, поэтому я должен быть более полезным. В последнее время я вижу увеличение количества способов, с помощью которых меня просят установить программное обеспечение, и по крайней мере для меня это раздражает.
- Несколько проектов попросят вас сделать что-то вроде curl http://bit.ly/installsh | sh, который загружает скрипт оболочки и выполняет его.
- Некоторые будут настаивать, чтобы у меня был установлен git
- Новый фреймворк может поставляться с собственным менеджером пакетов
Я программист полиглота (так что мне наплевать на # 3), который использует git для всего (скретч # 2) и который пишет небольшие скрипты bash, чтобы сделать мою жизнь проще (в точности как # 1). Поэтому я точно понимаю, как и почему эти решения выглядят хорошо. И для определенных обстоятельств они, в частности, для местного развития на машине, принадлежащей и обслуживаемой одним человеком. Но на производственной машине и даже на моих чистых и опрятных виртуальных машинах ни одна из них в большинстве случаев не подходила мне.
У большинства разработчиков, которых я знаю, есть только мимолетное понимание упаковки, поэтому я собираюсь немного рассказать о некоторых хитростях. Я думаю, что это то место, где системные администраторы ошибаются, они предполагают, что разработчики понимают свою работу и что они хорошо знают различные инструменты.
Советы по системному пакету
Я собираюсь показать примеры использования инструментов Debian, так что они применимы к дистрибутивам Debian и Ubuntu. RPM и инструмент Yum также имеют схожие команды, я просто лучше знаю дэбы.
Список всех установленных пакетов
Это немного очевидно, вероятно, оно будет доступно в любой домашней системе управления пакетами. Но если вы устанавливаете программное обеспечение вручную, используя git или скрипт оболочки, вы даже не можете спросить машину, что установлено.
dpkg -l
Список файлов из пакета
Я люблю это. Вы когда-нибудь устанавливали пакет и задавались вопросом, где находятся файлы конфигурации? Вы можете догадаться, основываясь на вашем понимании структуры файловой системы ОС, но эта команда удобна.
dpkg -L lynx /. /usr /usr/share /usr/share/doc /usr/share/doc/lynx /usr/share/doc/lynx/copyright /usr/share/doc/lynx/changelog.gz /usr/share/doc/lynx/changelog.Debian.gz
Откуда этот файл?
Есть файл на диске, который вы не знаете, откуда он взялся? Спросите системного менеджера пакетов. Чем больше всего установлено из пакетов, тем полезнее это становится.
dpkg -S /bin/netstat
Неудовлетворенные зависимости
В основе хорошей системы пакетов лежит способность отображать зависимости и устанавливать неудовлетворенные зависимости по мере необходимости. Наличие инструментов для запроса этого дерева полезно в разных местах.
apt-cache unmet
Вы получите вывод, похожий на следующий:
Package libdataobjects-sqlite3-ruby1.9.1 version 0.10.1.1-1 has an unmet dep: Depends: libdataobjects-ruby1.9
Что нуждается в обновлении?
Инструмент apticron может предупредить вас о пакетах, которые сейчас устарели. Это легко настроить, чтобы каждый день отправлять вам электронные письма для каждого хоста и сообщать вам о пакетах, которые необходимо обновить. Помните, что причиной того, что у одного из них может быть обновление, может быть задокументированная ошибка безопасности, и становится еще важнее быстро узнать о ней.
apticron report [Fri, 19 Jan 2007 18:42:01 -0800] ======================================================================== apticron has detected that some packages need upgrading on: faustus.example.com [ 1.2.3.4 ] The following packages are currently pending an upgrade: xfree86-common 4.3.0.dfsg.1-14sarge3 libice6 4.3.0.dfsg.1-14sarge3 libsm6 4.3.0.dfsg.1-14sarge3 xlibs-data 4.3.0.dfsg.1-14sarge3 libx11-6 4.3.0.dfsg.1-14sarge3 libxext6 4.3.0.dfsg.1-14sarge3 libxpm4 4.3.0.dfsg.1-14sarge3
Я действительно не эксперт по использованию дэбов, но даже я нахожу эти инструменты полезными, и вы не получаете те же возможности, когда используете что-то еще.
Хорошие и плохие примеры
Все еще здесь? Хороший. Я собираюсь выбрать несколько программ, чтобы привести примеры того, что я имею в виду. Все это программное обеспечение, которым я активно пользуюсь и которое я считаю, является просто потрясающим, я не оспариваю это программное обеспечение, поэтому, если кто-то из читающих фанатов может любезно не атаковать меня, пожалуйста, я один из вас.
RabbitMQ (Erlang)
Хороший народ, создающий очередь сообщений RabbitMQ, обеспечивает загрузку исходного кода, а также различные системные пакеты . Зная, что некоторые люди захотят использовать последнюю и лучшую версию приложения, они также размещают последние пакеты deboan в своем репозитории с подробностями на своем сайте .
Шеф-повар (Рубин)
Система управления конфигурацией Chef также предоставляет несколько способов установки программного обеспечения. Для людей, уже использующих, счастливых и знакомых с этим, они предоставляют все как рубиновый драгоценный камень. Если вы предпочитаете системные пакеты, они тоже есть . Они также предоставляют свои собственные репо для людей, чтобы получить новейшее программное обеспечение.
Cloudera Hadoop (Java)
До того, как я нашел пакеты Cloudera Hadoop, я помню, как получал огромное удовольствие от ручного применения патчей, чтобы все заработало. Cloudera делает то же самое, что и вышеперечисленные разработчики, а именно размещает свои собственные дэбы .
РВМ
RVM — это фантастический способ управления несколькими версиями ruby и несколькими изолированными наборами драгоценных камней. Но это также, вероятно, первое место, где я увидел установку из сценария удаленной оболочки.
bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )
Мне нравится делать на своей машине для разработки те же вещи, что и на производстве, и главная проблема, с которой я сталкиваюсь с RVM, заключается в том, что это настолько полезно, что я хочу этого везде. Я бы предпочел, чтобы у общесистемной установки была какая-то опция для установки рубинов из пакетов, а не для компиляции всего на компьютере (это означает, что вам нужен полный набор инструментов компиляции, установленных повсюду), или чтобы мы могли автоматизировать создание пакеты, использующие rvm.
Solr
Вы, вероятно, найдете пакеты для поискового сервера Solr в последних дистрибутивах. Он чрезвычайно популярен, потому что это фантастическое программное обеспечение. Но каждый раз, когда я смотрю на системные пакеты, я не могу заставить их работать, или они устарели. Теперь я достаточно хорошо разбираюсь в настройке Solr и в итоге создаю свои собственные пакеты, и я поговорил с другими людьми, которые сделали то же самое. Документация Solr рекомендует загрузить zip-файл, чтобы начать работу, и я не вижу упоминаний о пакетах. Я предполагаю, что пакеты не поддерживаются как часть разработки ядра, что является быстрым способом вывести их из синхронизации с текущим прогрессом.
Хватит избивать моих коллег-разработчиков
Системные пакеты не являются безупречными, я думаю, что культура, часто встречающаяся в Debian для отделения разработчика от сопровождающего пакета, является частью проблемы. Это проявляется по-разному, все отрицательно:
- Устаревшие пакеты. Самая большая жалоба разработчиков на системные пакеты почти всегда заключается в том, что они устарели. Сопровождающие должны с большей готовностью выпускать сценарии упаковки (в идеале обратно в проект), чтобы люди могли легко создавать свои собственные.
- Документация по упаковке либо фантастическая, либо ужасная, в зависимости от того, что вы хотите сделать и кто вы есть. Оказывается, создавать собственные пакеты (используя что-то вроде checkinstall ) на самом деле довольно просто.
- Я думаю, что официальные документы по Debian сосредоточены на роли сопровождающего пакета, а не на том, чтобы донести это до разработчиков. Это не делает их плохими, это просто означает, что нам нужна документация, предназначенная для разработчика, который только начинает упаковывать свое программное обеспечение
- Разработчики, размещающие свой собственный репозиторий пакетов и просящие людей указать на это, также довольно просты. Проекты, которые я оценил прежде всего, делают это хорошо. Но простую привлекательную документацию трудно найти.
Что делать
Сначала поговорим о распространении и установке программного обеспечения. И давайте сделаем это в духе улучшения ситуации для всех участников. Продолжающаяся ссора между людьми из Ruby и Debian просто контрпродуктивна. Это была бы хорошая статья, если бы она не приводила к:
Эта система (apt-get) устарела и приводит к серьезным головным болям. Избегайте его для пакетов, связанных с Ruby. Мы делаем Руби, мы знаем, что лучше. Верь нам.
Нам нужна лучшая документация для разработчиков. Вскоре я попытаюсь написать несколько кратких руководств (в противном случае я чувствовал бы, что эта напыщенная речь была только мной жаловаться), но я не эксперт. Я с радостью помогу продвинуть или сопоставить хороший материал. Может быть, он уже существует, и я просто не могу его найти?
Я — пользователь git и большой поклонник GitHub , но одна из особенностей Launchpad, которая мне действительно нравится, — это архив личных пакетов . Это позволяет загружать исходный код и автоматически встраивать его в пакет. Это относится к Ubuntu, но это понятно, учитывая, что Launchpad также управляется Canonical. Мне бы хотелось, чтобы в GitHub была та же функция, но она позволяла создавать дэбы и RPM для разных архитектур. В качестве альтернативы, сторонняя сторонняя организация, которая могла бы сделать то же самое, была бы великолепна (кто-нибудь хочет создать ее? Единственным реальным преимуществом GitHub является то, что он сразу делает пакеты крутыми, что, надеюсь, вы все теперь понимаете, что это так.