Comments 47
UFO just landed and posted this here
Может, стоит перенести в блог Убунтариум?..
0
Когда в следующий раз появится статья про «установим PHP из исходников», буду на Вашу ссылаться, как на образец.
Спасибо!
Спасибо!
0
UFO just landed and posted this here
Можно попробовать checkinstall, который сделает почти всю грязную работу сам.
0
Смысл был не в том, что бы установить пакет на локальной машине, а что бы на локальной машине собрать пакет и установить его на серверах
-1
Гораздо полезнее было бы подготовить директорию для сборки пакета со всякими control.
Потому что автоматически собранный пакет это совсем не то, что надо — надо подправить стартовые скрипты, настройки в /etc/default кинуть и тп.
Мне больше понравился вариант с tap2deb — эта утилита готовит для приложения на twisted все требуемое — остается обтесать и собирать.
Потому что автоматически собранный пакет это совсем не то, что надо — надо подправить стартовые скрипты, настройки в /etc/default кинуть и тп.
Мне больше понравился вариант с tap2deb — эта утилита готовит для приложения на twisted все требуемое — остается обтесать и собирать.
0
Какие отличия будут для убунту?
Как пропписать действие(!) при установке обновлении, чтобы прописать в другие конфиги пару строк?
Как пропписать действие(!) при установке обновлении, чтобы прописать в другие конфиги пару строк?
0
В убунту те же менеджеры пакетов. apt и aptitude.
0
Ну я поэтому и спросил, какие отличия.
postinst файл — ответ на мой второй вопрос.
postinst файл — ответ на мой второй вопрос.
-1
Да тупо добавляешь свою репу в sources.list и будет тебе счастье. Вот же беда…
0
Я задал вполне конкретный вопрос, если что. Можно не отвечать: отличий нет. Но вот прочитать вопрос перед ответом все же было желательно.
0
У нас как раз пакет собирается на локальной машине с Ubuntu, а заливается на офисный сервер с Ubuntu Server и на площадку на Debian Lenny.
Для выливки с++ кода на Debian есть одна проблема — версии пакетов зависимостей могу не совпадать. Для её решения мы используем chroot дебиана на локальной машине с ubuntu в котором версии пакетов те же что и на бою. В chroot-е собирается пакет, а потом выливается на бой.
Для выливки с++ кода на Debian есть одна проблема — версии пакетов зависимостей могу не совпадать. Для её решения мы используем chroot дебиана на локальной машине с ubuntu в котором версии пакетов те же что и на бою. В chroot-е собирается пакет, а потом выливается на бой.
+1
pbuilder?
0
Нет. Сделал как написано тут DebootstrapChroot. А pbuilder посмотрю, спасибо.
0
UFO just landed and posted this here
Кстати все таки советую не лениться, а сделать свой ключ и подписывать им репозитарий и внести его в доверенные на всех серверах. В интернетах были руководства и готовые скрипты для автоматизации.
Вот когда то давно писал — deepwalker.blogspot.com/2008/03/ubuntu.html
Вот когда то давно писал — deepwalker.blogspot.com/2008/03/ubuntu.html
+2
Где Вы были два дня назад, когда я читал многостраничные мануалы)
Спасибо, в избранное.
Спасибо, в избранное.
0
Это работающий, но не совсем правильный способ сборки deb-пакета.
Для облегчения этой задачи есть набор утилит debhelper, которые позволяют создавать «рыбы» пакетов, автоматически заполнять их и собирать, соблюдая все зависимости (debuild).
Если интересно — могу немного рассказать.
Для облегчения этой задачи есть набор утилит debhelper, которые позволяют создавать «рыбы» пакетов, автоматически заполнять их и собирать, соблюдая все зависимости (debuild).
Если интересно — могу немного рассказать.
+1
в составе утилит серии dh_make есть утилитка, котрая автоматически вычисляет зависимостии запихивает их в заголовок пакета
хотя для пакета-сайта, оно, конечно, не требуется.
хотя для пакета-сайта, оно, конечно, не требуется.
0
Плюсанул. Но всё равно PKGBUILD`ы рулят %)
0
А что вы подразумеваете под «выливки сайта на сервер»? Весь серверный код (php/python-скрипты), вёрстку, картинки?
Нельзя ли пару слов о преимуществах перед (например) какими-нибудь скриптами для SCM-системы, которая закачивает изменения на сервак (вроде для svn это можно делаеть через хуки, не уверен)? Для чего это, что даёт?
Нельзя ли пару слов о преимуществах перед (например) какими-нибудь скриптами для SCM-системы, которая закачивает изменения на сервак (вроде для svn это можно делаеть через хуки, не уверен)? Для чего это, что даёт?
0
Да именно — код на 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 подтверждает это. Лучше пушить код на сервер, который ничего не знает о сервере, где код хранится. Но это сугубо моё личное мнение.
0
Сам некоторое время собирал свой проект именно так, сляпанным на коленке control-файлом и dpkg -b :)
Потом всё-таки собрался с духом и довёл до ума, чтобы собиралось с помощью dpkg-buildpackage, теперь горя не знаю: заливаю на OBS и он собирает мне под любые архитектуры и любые релизы Дебиана/Убунты.
Остался последний шаг, который я всё никак не соберусь сделать: надо добавить gpg-ключ.
Потом всё-таки собрался с духом и довёл до ума, чтобы собиралось с помощью dpkg-buildpackage, теперь горя не знаю: заливаю на OBS и он собирает мне под любые архитектуры и любые релизы Дебиана/Убунты.
Остался последний шаг, который я всё никак не соберусь сделать: надо добавить gpg-ключ.
+1
есть программа checkinstall, которая из исходников делает и .rpm и .deb, а заодно и устанавливать в систему этот пакет может. версию и зависимости можно прописывать интерактивно.
0
то как это делает чекинсталл… лучше бы и не делало.
ни зависимостей, ничего.
единственный толк от него это возможность потом штатно удалить, а не вычищать систему.
а уважаемый коллега все же писал статью как сделать пакет который будет ставится на другие сервера+к тому с зависимостями и версионностью.
ни зависимостей, ничего.
единственный толк от него это возможность потом штатно удалить, а не вычищать систему.
а уважаемый коллега все же писал статью как сделать пакет который будет ставится на другие сервера+к тому с зависимостями и версионностью.
0
при использовании checkinstall можно задавать зависимости. Автор же предлагает точно также указывать зависимости в файлике с незатейливым именем «control»
0
на самом деле, чем руками создавать control и товарищи тебе тут правильно рекомендуют dh_make, который создает болванку директории со всеми файлами.
я тут просто свежий luarocks в пакетик заворачиваю, вот и столкнулся с вопросом тоже :)
я тут просто свежий luarocks в пакетик заворачиваю, вот и столкнулся с вопросом тоже :)
0
Было бы очень интересно почитать про приемущества такого способа (deb-пакеты) для обновления сайта перед остальными (svn, к примеру) в отдельной статье. А то методика есть, а цель её не совсем ясна. Да и в Сети таких статей (сравнений методов обновления сайта) я, к сожалению, не нашёл :(
Привести примеры задач, для которых это требуется и т.д.
P.S. Да, в комментариях выше это частично объясняется, но только частично. Хотелось бы более развёрнуто.
Привести примеры задач, для которых это требуется и т.д.
P.S. Да, в комментариях выше это частично объясняется, но только частично. Хотелось бы более развёрнуто.
0
Ну тут дело не в преимуществе одного метода над другим, а выборе верного метода под конкретную задачу. К примеру:
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 в недалеком будущем. После этого постараюсь оформить полученный опыт в статью, в которой сравнить все три указанных подхода.
+1
Sign up to leave a comment.
deb-пакет на коленке