Comments 47
UFO just landed and posted this here
Может, стоит перенести в блог Убунтариум?..
Когда в следующий раз появится статья про «установим PHP из исходников», буду на Вашу ссылаться, как на образец.
Спасибо!
Спасибо!
UFO just landed and posted this here
Можно попробовать 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 (детальнее тут).
UFO just landed and posted this here
Кстати все таки советую не лениться, а сделать свой ключ и подписывать им репозитарий и внести его в доверенные на всех серверах. В интернетах были руководства и готовые скрипты для автоматизации.
Вот когда то давно писал — 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 в недалеком будущем. После этого постараюсь оформить полученный опыт в статью, в которой сравнить все три указанных подхода.
Sign up to leave a comment.
deb-пакет на коленке