Комментарии 47
НЛО прилетело и опубликовало эту надпись здесь
Может, стоит перенести в блог Убунтариум?..
Когда в следующий раз появится статья про «установим PHP из исходников», буду на Вашу ссылаться, как на образец.
Спасибо!
Спасибо!
НЛО прилетело и опубликовало эту надпись здесь
Можно попробовать checkinstall, который сделает почти всю грязную работу сам.
Смысл был не в том, что бы установить пакет на локальной машине, а что бы на локальной машине собрать пакет и установить его на серверах
Гораздо полезнее было бы подготовить директорию для сборки пакета со всякими control.
Потому что автоматически собранный пакет это совсем не то, что надо — надо подправить стартовые скрипты, настройки в /etc/default кинуть и тп.
Мне больше понравился вариант с tap2deb — эта утилита готовит для приложения на twisted все требуемое — остается обтесать и собирать.
Потому что автоматически собранный пакет это совсем не то, что надо — надо подправить стартовые скрипты, настройки в /etc/default кинуть и тп.
Мне больше понравился вариант с tap2deb — эта утилита готовит для приложения на twisted все требуемое — остается обтесать и собирать.
Какие отличия будут для убунту?
Как пропписать действие(!) при установке обновлении, чтобы прописать в другие конфиги пару строк?
Как пропписать действие(!) при установке обновлении, чтобы прописать в другие конфиги пару строк?
В убунту те же менеджеры пакетов. apt и aptitude.
У нас как раз пакет собирается на локальной машине с Ubuntu, а заливается на офисный сервер с Ubuntu Server и на площадку на Debian Lenny.
Для выливки с++ кода на Debian есть одна проблема — версии пакетов зависимостей могу не совпадать. Для её решения мы используем chroot дебиана на локальной машине с ubuntu в котором версии пакетов те же что и на бою. В chroot-е собирается пакет, а потом выливается на бой.
Для выливки с++ кода на Debian есть одна проблема — версии пакетов зависимостей могу не совпадать. Для её решения мы используем chroot дебиана на локальной машине с ubuntu в котором версии пакетов те же что и на бою. В chroot-е собирается пакет, а потом выливается на бой.
pbuilder?
Нет. Сделал как написано тут DebootstrapChroot. А pbuilder посмотрю, спасибо.
Для задания действия при установке достаточно добавить shell скрипт с именем postinst (детальнее тут).
НЛО прилетело и опубликовало эту надпись здесь
Кстати все таки советую не лениться, а сделать свой ключ и подписывать им репозитарий и внести его в доверенные на всех серверах. В интернетах были руководства и готовые скрипты для автоматизации.
Вот когда то давно писал — deepwalker.blogspot.com/2008/03/ubuntu.html
Вот когда то давно писал — deepwalker.blogspot.com/2008/03/ubuntu.html
Где Вы были два дня назад, когда я читал многостраничные мануалы)
Спасибо, в избранное.
Спасибо, в избранное.
Это работающий, но не совсем правильный способ сборки deb-пакета.
Для облегчения этой задачи есть набор утилит debhelper, которые позволяют создавать «рыбы» пакетов, автоматически заполнять их и собирать, соблюдая все зависимости (debuild).
Если интересно — могу немного рассказать.
Для облегчения этой задачи есть набор утилит debhelper, которые позволяют создавать «рыбы» пакетов, автоматически заполнять их и собирать, соблюдая все зависимости (debuild).
Если интересно — могу немного рассказать.
в составе утилит серии dh_make есть утилитка, котрая автоматически вычисляет зависимостии запихивает их в заголовок пакета
хотя для пакета-сайта, оно, конечно, не требуется.
хотя для пакета-сайта, оно, конечно, не требуется.
Плюсанул. Но всё равно PKGBUILD`ы рулят %)
А что вы подразумеваете под «выливки сайта на сервер»? Весь серверный код (php/python-скрипты), вёрстку, картинки?
Нельзя ли пару слов о преимуществах перед (например) какими-нибудь скриптами для SCM-системы, которая закачивает изменения на сервак (вроде для svn это можно делаеть через хуки, не уверен)? Для чего это, что даёт?
Нельзя ли пару слов о преимуществах перед (например) какими-нибудь скриптами для SCM-системы, которая закачивает изменения на сервак (вроде для svn это можно делаеть через хуки, не уверен)? Для чего это, что даёт?
Да именно — код на php, swf-ки, верстка, статические картинки. Ну а так же все демоны, обслуживающие сайт. Как раз из-за демонов и было прийнято решение перейти на пакеты.
Используя пакеты вместо VCS облегчается сама выливка. И её может проводить не программист, а админ (который умеет работать с пакетной системой и не хочет знать что такое код и как его выливать).
Для выливок сугубо скриптовой части, в принципе, подойдут и Capistrano, Vlad the Deployer и похожие утилиты (они могут забирать исходики с VCS, но это не отменяет того, что их можно использовать в комбинации с пакетами).
Раньше мы использовали такую схему: на офисном сервере делали чекаут конкретной версии исходников, rsync-ом заливали код на все сервера и билдили демоны на каждой машине. Тогда боевые сервера были на Gentoo и такой метод был приемлем, хотя и вызывал более длительные выливки чем нам хотелось. Сейчас мы перешли на Debian и использовать его пакетную систему было логично. К слову раньше минимальная выливка занимала около полу часа (пока зальются все изменения, пока соберется код). Теперь все пакеты загружены на сервер до выливки. Админ вызывает apt-get install, рестартует демоны и проводит небольшую проверку. Это занимает отсилы 5 минут.
А пулить код с боевого сервера не такая уж и хорошая идея. Недавняя история с уязвимостю с svn подтверждает это. Лучше пушить код на сервер, который ничего не знает о сервере, где код хранится. Но это сугубо моё личное мнение.
Используя пакеты вместо VCS облегчается сама выливка. И её может проводить не программист, а админ (который умеет работать с пакетной системой и не хочет знать что такое код и как его выливать).
Для выливок сугубо скриптовой части, в принципе, подойдут и Capistrano, Vlad the Deployer и похожие утилиты (они могут забирать исходики с VCS, но это не отменяет того, что их можно использовать в комбинации с пакетами).
Раньше мы использовали такую схему: на офисном сервере делали чекаут конкретной версии исходников, rsync-ом заливали код на все сервера и билдили демоны на каждой машине. Тогда боевые сервера были на Gentoo и такой метод был приемлем, хотя и вызывал более длительные выливки чем нам хотелось. Сейчас мы перешли на Debian и использовать его пакетную систему было логично. К слову раньше минимальная выливка занимала около полу часа (пока зальются все изменения, пока соберется код). Теперь все пакеты загружены на сервер до выливки. Админ вызывает apt-get install, рестартует демоны и проводит небольшую проверку. Это занимает отсилы 5 минут.
А пулить код с боевого сервера не такая уж и хорошая идея. Недавняя история с уязвимостю с svn подтверждает это. Лучше пушить код на сервер, который ничего не знает о сервере, где код хранится. Но это сугубо моё личное мнение.
Сам некоторое время собирал свой проект именно так, сляпанным на коленке control-файлом и dpkg -b :)
Потом всё-таки собрался с духом и довёл до ума, чтобы собиралось с помощью dpkg-buildpackage, теперь горя не знаю: заливаю на OBS и он собирает мне под любые архитектуры и любые релизы Дебиана/Убунты.
Остался последний шаг, который я всё никак не соберусь сделать: надо добавить gpg-ключ.
Потом всё-таки собрался с духом и довёл до ума, чтобы собиралось с помощью dpkg-buildpackage, теперь горя не знаю: заливаю на OBS и он собирает мне под любые архитектуры и любые релизы Дебиана/Убунты.
Остался последний шаг, который я всё никак не соберусь сделать: надо добавить gpg-ключ.
есть программа checkinstall, которая из исходников делает и .rpm и .deb, а заодно и устанавливать в систему этот пакет может. версию и зависимости можно прописывать интерактивно.
то как это делает чекинсталл… лучше бы и не делало.
ни зависимостей, ничего.
единственный толк от него это возможность потом штатно удалить, а не вычищать систему.
а уважаемый коллега все же писал статью как сделать пакет который будет ставится на другие сервера+к тому с зависимостями и версионностью.
ни зависимостей, ничего.
единственный толк от него это возможность потом штатно удалить, а не вычищать систему.
а уважаемый коллега все же писал статью как сделать пакет который будет ставится на другие сервера+к тому с зависимостями и версионностью.
на самом деле, чем руками создавать control и товарищи тебе тут правильно рекомендуют dh_make, который создает болванку директории со всеми файлами.
я тут просто свежий luarocks в пакетик заворачиваю, вот и столкнулся с вопросом тоже :)
я тут просто свежий luarocks в пакетик заворачиваю, вот и столкнулся с вопросом тоже :)
Было бы очень интересно почитать про приемущества такого способа (deb-пакеты) для обновления сайта перед остальными (svn, к примеру) в отдельной статье. А то методика есть, а цель её не совсем ясна. Да и в Сети таких статей (сравнений методов обновления сайта) я, к сожалению, не нашёл :(
Привести примеры задач, для которых это требуется и т.д.
P.S. Да, в комментариях выше это частично объясняется, но только частично. Хотелось бы более развёрнуто.
Привести примеры задач, для которых это требуется и т.д.
P.S. Да, в комментариях выше это частично объясняется, но только частично. Хотелось бы более развёрнуто.
Ну тут дело не в преимуществе одного метода над другим, а выборе верного метода под конкретную задачу. К примеру:
1. git/svn/hg/… — для контроля версий
2. deb/rpm/… — для хранения бинарных данных, трекинга зависимостей, менеджмента версий средствами ОС
3. capistrano/vlad the deployer/… — для автоматизации работы на нескольких серверах, автоматизации выливки и отката изменений и тд.
Для простого сайта на одном сервере, выливка на который сводится только к обновлению версии кода, вполне подойдет использование сугубо vcs.
Для сайта на одном-двух серверах, который состоит из нескольких модулей и сложными зависимостями на установленые приложения (либо включает в себя компоненты на с/c++, которые должны быть собраны в бинарники) — оптимальным будет использование пакетов, так как часть работы ложится на пакетный менеджер ОС.
Для развернутых на большом числе машин и сложной системой развартывания — лучше использовать специальные системы деплоя типа capistrano. Причем можно использовать в комбинации как с vcs, так и с теми же пакетами.
У меня мало опыта работы с системами автоматического деплоя, но есть планы по внедрению capistrano в недалеком будущем. После этого постараюсь оформить полученный опыт в статью, в которой сравнить все три указанных подхода.
1. git/svn/hg/… — для контроля версий
2. deb/rpm/… — для хранения бинарных данных, трекинга зависимостей, менеджмента версий средствами ОС
3. capistrano/vlad the deployer/… — для автоматизации работы на нескольких серверах, автоматизации выливки и отката изменений и тд.
Для простого сайта на одном сервере, выливка на который сводится только к обновлению версии кода, вполне подойдет использование сугубо vcs.
Для сайта на одном-двух серверах, который состоит из нескольких модулей и сложными зависимостями на установленые приложения (либо включает в себя компоненты на с/c++, которые должны быть собраны в бинарники) — оптимальным будет использование пакетов, так как часть работы ложится на пакетный менеджер ОС.
Для развернутых на большом числе машин и сложной системой развартывания — лучше использовать специальные системы деплоя типа capistrano. Причем можно использовать в комбинации как с vcs, так и с теми же пакетами.
У меня мало опыта работы с системами автоматического деплоя, но есть планы по внедрению capistrano в недалеком будущем. После этого постараюсь оформить полученный опыт в статью, в которой сравнить все три указанных подхода.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
deb-пакет на коленке