Оу, я тааак далёк от школ, их администрирования и в принципе от администрирования рабочих станций… Вообще не знаю, как там, чего, куда и зачем. Расскажете?
а) Я вижу минус в множении сущностей. В вашем варианте необходим как свой репозиторий с пакетами mycompany*, так и puppet, который будет отслеживать эти самые апдейты. В моем варианте репозиторий не нужен, а конфиг можно легко править на мастере без необходимости сборки-разборки пакета. Я не спорю, вариант с пакетами имеет право на существование, но мне он не нравится потому что прозреваю там большее количество возни и большую вероятность ошибок.
б) Совсем не плохая. Тут описан хороший вариант динамической генерации манифестов и их применения. И знаете, банально менять конфиг одного виртуального хоста в nginx'e через пересборку пакета — это за гранью добра и зла.
Здесь используется инлайн-конфиг, который делает манифест некрасивым. На самом деле так почти никогда не делается, существует механизм шаблонов, основанный на ERB, и возможность просто использовать внешние файлы. Но нас не это интересует.
Да, это грязно, да, так не делают. Здесь пример используется для показа работы зависимостей.
По моему опыту конфиги лучше описывать всё же в puppet, а не складывать их в пакеты по следующим причинам:
а) Апстрим всегда апстрим, а свои руки я считаю кривее рук мейнтейнеров. Если выйдет хот-секьюрити-фикс на openssh-server, puppet подтянет его сам (ensure => latest), а мне придётся прочитать об этом из рассылки, пересобрать пакет (руками! а я от этого избавиться пытаюсь), положить в репозиторий и только после этого ноды вытянут (опять же, через ensure => latest) новый пакет.
б) Один инструмент вместо нескольких. Я вдруг захочу изменить на всех серверах порт ssh с 22 на 45802. Мне надо разобрать пакет, заменить конфиг, собрать пакет, дёрнуть на всех нодах aptitude update && aptitude safe-upgrade (пусть и через puppet). Это работает для простого сервиса с несложным конфигом. Когда мне понадобится компилировать уникальный конфиг для каждой ноды на основании каких-либо их уникальных данных, полученных через facter или еще как-нибудь — я взвою и задумаюсь, что наверное puppet я использую как-то не так.
Всё верно, пакетный менеджер описывает состояние системы. Сделайте на любом своём сервере (на примере debian) dpkg -l | awk '{print $2}' > list, установите голую систему, запустите там for i in $(cat list); do apt-get install $i; done. Если после этого у вас серверы станут идентичными — жму руку. Я к тому, что пакетный менеджер описывает состояние системы, но не сервисов, которые эта система предоставляет (слово сервис здесь в широком смысле).
Dev-testing-stable я решаю с помощью лабораторий с отдельным окружением. В век виртуализации это не сложно. Гит помогает в плане упорядочивания изменений и хранения истории.
Влад, имхо твои лекции были лучшими из всех на этом КИТе, без преувеличения.
Хотя, может быть, это потому, что из всего, что нам читали, сети я знал хуже всего.
В сутках 1440 минут, в рабочих 8 часах — 560. Даже если взять 12 часов — то будет всего 720 минут. Вспомните, сколько времени вы тратите на общение с банкоматом? Я редко стою меньше 1 минуты, обычно 2-3. За рабочий день один банкомат обслужит 200-400 человек, а вовсе не 3-4 тысячи.
Конечно, это базовая функциональность.
Самый простой конфиг:
rtmp {
server {
listen 1935;
application live {
live on;
}
}
}
Все, что вы будете паблишить в сервер с энкодера в приложение live будет отдаваться клиентам.
Чтобы разрешить паблишить только с определённых IP, нужно использовать директиву allow publish, например:
rtmp {
server {
listen 1935;
application live {
live on;
allow publish 127.0.0.1
}
}
}
На четырёхъядерном сервере в 4 потока с разных IP-адресов в синтетическом тесте я смог вытащить с сервера около 9к подключений по мегабиту на каждое. Дальше упёрся в сеть.
б) Совсем не плохая. Тут описан хороший вариант динамической генерации манифестов и их применения. И знаете, банально менять конфиг одного виртуального хоста в nginx'e через пересборку пакета — это за гранью добра и зла.
Да, это грязно, да, так не делают. Здесь пример используется для показа работы зависимостей.
По моему опыту конфиги лучше описывать всё же в puppet, а не складывать их в пакеты по следующим причинам:
а) Апстрим всегда апстрим, а свои руки я считаю кривее рук мейнтейнеров. Если выйдет хот-секьюрити-фикс на openssh-server, puppet подтянет его сам (ensure => latest), а мне придётся прочитать об этом из рассылки, пересобрать пакет (руками! а я от этого избавиться пытаюсь), положить в репозиторий и только после этого ноды вытянут (опять же, через ensure => latest) новый пакет.
б) Один инструмент вместо нескольких. Я вдруг захочу изменить на всех серверах порт ssh с 22 на 45802. Мне надо разобрать пакет, заменить конфиг, собрать пакет, дёрнуть на всех нодах aptitude update && aptitude safe-upgrade (пусть и через puppet). Это работает для простого сервиса с несложным конфигом. Когда мне понадобится компилировать уникальный конфиг для каждой ноды на основании каких-либо их уникальных данных, полученных через facter или еще как-нибудь — я взвою и задумаюсь, что наверное puppet я использую как-то не так.
Всё верно, пакетный менеджер описывает состояние системы. Сделайте на любом своём сервере (на примере debian) dpkg -l | awk '{print $2}' > list, установите голую систему, запустите там for i in $(cat list); do apt-get install $i; done. Если после этого у вас серверы станут идентичными — жму руку. Я к тому, что пакетный менеджер описывает состояние системы, но не сервисов, которые эта система предоставляет (слово сервис здесь в широком смысле).
Dev-testing-stable я решаю с помощью лабораторий с отдельным окружением. В век виртуализации это не сложно. Гит помогает в плане упорядочивания изменений и хранения истории.
Хотя, может быть, это потому, что из всего, что нам читали, сети я знал хуже всего.
Кто вы и где Mithgol?
Самый простой конфиг:
Все, что вы будете паблишить в сервер с энкодера в приложение live будет отдаваться клиентам.
Чтобы разрешить паблишить только с определённых IP, нужно использовать директиву allow publish, например:
Особенно домен доставил.
Ознакомьтесь с сабжем на википедии.
В каждом топике, где есть упоминание GPS, есть и человек, который говорит, что A-GPS ненастоящий. Когда это кончится?