AK
у меня есть инструмент для организации репозиториев и он уже сделан. у меня вопрос про генерацию REPO файла с этими локальными репами.
Size: a a a
2020 April 09
SP
у меня есть инструмент для организации репозиториев и он уже сделан. у меня вопрос про генерацию REPO файла с этими локальными репами.
дядь ты тоже читать не умеешь?
я тебе назвал инструмент, который генерирует REPO файлы с этими локальными репами.
я тебе назвал инструмент, который генерирует REPO файлы с этими локальными репами.
AK
дядь ты тоже читать не умеешь?
я тебе назвал инструмент, который генерирует REPO файлы с этими локальными репами.
я тебе назвал инструмент, который генерирует REPO файлы с этими локальными репами.
артифактори вроде тоже не умеет их генерить
SP
артифактори вроде тоже не умеет их генерить
Платный - умеет.
AK
Платный - умеет.
ну платный нам никто не купит
AK
так что увы)
AK
я через nexus oss собрал все
SP
pypi/npm/rhel/cenos/debian/alp/ubuntu и тд
>ну платный нам никто не купит
Ты же в жыртыпрайзе работаешь, судя по разнообразию реп 😃
Ты же в жыртыпрайзе работаешь, судя по разнообразию реп 😃
AK
>ну платный нам никто не купит
Ты же в жыртыпрайзе работаешь, судя по разнообразию реп 😃
Ты же в жыртыпрайзе работаешь, судя по разнообразию реп 😃
в госе
AK
проще застрелиться чем купить что-то)
SP
в госе
Ну ещё какой жыртыпрайз же. Астра, Роса, вот это вот всё.
AK
Ну ещё какой жыртыпрайз же. Астра, Роса, вот это вот всё.
бл... точно. еще репу с астрой надо сделать... спасибо!)
SP
бл... точно. еще репу с астрой надо сделать... спасибо!)
G
несколько туповатый вопрос может быть.
Есть jenkins pipeline в котором надо проверить нет ли в проекте, собираемом gradle-ом, зависимостей со снэпшотными версиями. Есть идеи как это с наименьшими трудозатратами реализовать? Хотя бы направление куда копать
Есть jenkins pipeline в котором надо проверить нет ли в проекте, собираемом gradle-ом, зависимостей со снэпшотными версиями. Есть идеи как это с наименьшими трудозатратами реализовать? Хотя бы направление куда копать
ИТ
Grigorii
несколько туповатый вопрос может быть.
Есть jenkins pipeline в котором надо проверить нет ли в проекте, собираемом gradle-ом, зависимостей со снэпшотными версиями. Есть идеи как это с наименьшими трудозатратами реализовать? Хотя бы направление куда копать
Есть jenkins pipeline в котором надо проверить нет ли в проекте, собираемом gradle-ом, зависимостей со снэпшотными версиями. Есть идеи как это с наименьшими трудозатратами реализовать? Хотя бы направление куда копать
sh скрипт
я как-то делал что-то похожее
я как-то делал что-то похожее
AK
Всем доброго времени суток!
Скажите, пользуется ли кто-нибудь Tekton Piplines или Concourse?
Скажите, пользуется ли кто-нибудь Tekton Piplines или Concourse?
DS
Уточняю: до сих пор помню, как выходит ГД фланта и вещает:
- берём 3 железки в ХЦ
- наливаем цеф
- сверху наливаем кубер
- сверху виртуализацию
И это наше решение всех ваших проблем
- берём 3 железки в ХЦ
- наливаем цеф
- сверху наливаем кубер
- сверху виртуализацию
И это наше решение всех ваших проблем
Привет! Уже не раз встречаю от тебя подобные заявления, поэтому пора развёрнуто высказаться.
Решение, о котором идет речь, — практика, что мы действительно использовали для ряда клиентов на момент публикации доклада про «Kubernetes для небольших проектов», т.е. лето 2017 года. Причины для этого, а точнее — случаи, в которых оно применялось, в целом примерно таковы:
1. Самые минимально возможные затраты на железки.
2. Когда нагрузки на дисковую подсистему тоже минимальны (production-базы там не запускались).
3. Когда нужны возможности Kubernetes с удобным persistent storage (быстрое создание dev-окружений и БД под них; pod’ы могут легко переезжать между машинами).
Да, это далеко от best practice, но workaround, который на тот момент позволял добиваться желаемого (K8s в маленьких проектах) небольшими средствами. В остальных случаях применялись другие подходы.
Со временем такой подход показал нам все подводные камни — ну, может, не все, но достаточное количество, чтобы значительно его переосмыслить. И мы полностью отказались от виртуалок на Ceph’е в таких проектах, делаем Kubernetes-узлы без виртуализации и т.п.
Поскольку такая схема и без важных уточнений описана в старом докладе, пожалуй, самое время актуализировать эту информацию. Мы напишем новую статью о нынешнем видении (и реализации) Kubernetes’а для небольших проектов — чтобы другие не повторяли ошибок. Спасибо за обратную связь!
Решение, о котором идет речь, — практика, что мы действительно использовали для ряда клиентов на момент публикации доклада про «Kubernetes для небольших проектов», т.е. лето 2017 года. Причины для этого, а точнее — случаи, в которых оно применялось, в целом примерно таковы:
1. Самые минимально возможные затраты на железки.
2. Когда нагрузки на дисковую подсистему тоже минимальны (production-базы там не запускались).
3. Когда нужны возможности Kubernetes с удобным persistent storage (быстрое создание dev-окружений и БД под них; pod’ы могут легко переезжать между машинами).
Да, это далеко от best practice, но workaround, который на тот момент позволял добиваться желаемого (K8s в маленьких проектах) небольшими средствами. В остальных случаях применялись другие подходы.
Со временем такой подход показал нам все подводные камни — ну, может, не все, но достаточное количество, чтобы значительно его переосмыслить. И мы полностью отказались от виртуалок на Ceph’е в таких проектах, делаем Kubernetes-узлы без виртуализации и т.п.
Поскольку такая схема и без важных уточнений описана в старом докладе, пожалуй, самое время актуализировать эту информацию. Мы напишем новую статью о нынешнем видении (и реализации) Kubernetes’а для небольших проектов — чтобы другие не повторяли ошибок. Спасибо за обратную связь!
VS
Привет! Уже не раз встречаю от тебя подобные заявления, поэтому пора развёрнуто высказаться.
Решение, о котором идет речь, — практика, что мы действительно использовали для ряда клиентов на момент публикации доклада про «Kubernetes для небольших проектов», т.е. лето 2017 года. Причины для этого, а точнее — случаи, в которых оно применялось, в целом примерно таковы:
1. Самые минимально возможные затраты на железки.
2. Когда нагрузки на дисковую подсистему тоже минимальны (production-базы там не запускались).
3. Когда нужны возможности Kubernetes с удобным persistent storage (быстрое создание dev-окружений и БД под них; pod’ы могут легко переезжать между машинами).
Да, это далеко от best practice, но workaround, который на тот момент позволял добиваться желаемого (K8s в маленьких проектах) небольшими средствами. В остальных случаях применялись другие подходы.
Со временем такой подход показал нам все подводные камни — ну, может, не все, но достаточное количество, чтобы значительно его переосмыслить. И мы полностью отказались от виртуалок на Ceph’е в таких проектах, делаем Kubernetes-узлы без виртуализации и т.п.
Поскольку такая схема и без важных уточнений описана в старом докладе, пожалуй, самое время актуализировать эту информацию. Мы напишем новую статью о нынешнем видении (и реализации) Kubernetes’а для небольших проектов — чтобы другие не повторяли ошибок. Спасибо за обратную связь!
Решение, о котором идет речь, — практика, что мы действительно использовали для ряда клиентов на момент публикации доклада про «Kubernetes для небольших проектов», т.е. лето 2017 года. Причины для этого, а точнее — случаи, в которых оно применялось, в целом примерно таковы:
1. Самые минимально возможные затраты на железки.
2. Когда нагрузки на дисковую подсистему тоже минимальны (production-базы там не запускались).
3. Когда нужны возможности Kubernetes с удобным persistent storage (быстрое создание dev-окружений и БД под них; pod’ы могут легко переезжать между машинами).
Да, это далеко от best practice, но workaround, который на тот момент позволял добиваться желаемого (K8s в маленьких проектах) небольшими средствами. В остальных случаях применялись другие подходы.
Со временем такой подход показал нам все подводные камни — ну, может, не все, но достаточное количество, чтобы значительно его переосмыслить. И мы полностью отказались от виртуалок на Ceph’е в таких проектах, делаем Kubernetes-узлы без виртуализации и т.п.
Поскольку такая схема и без важных уточнений описана в старом докладе, пожалуй, самое время актуализировать эту информацию. Мы напишем новую статью о нынешнем видении (и реализации) Kubernetes’а для небольших проектов — чтобы другие не повторяли ошибок. Спасибо за обратную связь!
👍
EG
Привет! Уже не раз встречаю от тебя подобные заявления, поэтому пора развёрнуто высказаться.
Решение, о котором идет речь, — практика, что мы действительно использовали для ряда клиентов на момент публикации доклада про «Kubernetes для небольших проектов», т.е. лето 2017 года. Причины для этого, а точнее — случаи, в которых оно применялось, в целом примерно таковы:
1. Самые минимально возможные затраты на железки.
2. Когда нагрузки на дисковую подсистему тоже минимальны (production-базы там не запускались).
3. Когда нужны возможности Kubernetes с удобным persistent storage (быстрое создание dev-окружений и БД под них; pod’ы могут легко переезжать между машинами).
Да, это далеко от best practice, но workaround, который на тот момент позволял добиваться желаемого (K8s в маленьких проектах) небольшими средствами. В остальных случаях применялись другие подходы.
Со временем такой подход показал нам все подводные камни — ну, может, не все, но достаточное количество, чтобы значительно его переосмыслить. И мы полностью отказались от виртуалок на Ceph’е в таких проектах, делаем Kubernetes-узлы без виртуализации и т.п.
Поскольку такая схема и без важных уточнений описана в старом докладе, пожалуй, самое время актуализировать эту информацию. Мы напишем новую статью о нынешнем видении (и реализации) Kubernetes’а для небольших проектов — чтобы другие не повторяли ошибок. Спасибо за обратную связь!
Решение, о котором идет речь, — практика, что мы действительно использовали для ряда клиентов на момент публикации доклада про «Kubernetes для небольших проектов», т.е. лето 2017 года. Причины для этого, а точнее — случаи, в которых оно применялось, в целом примерно таковы:
1. Самые минимально возможные затраты на железки.
2. Когда нагрузки на дисковую подсистему тоже минимальны (production-базы там не запускались).
3. Когда нужны возможности Kubernetes с удобным persistent storage (быстрое создание dev-окружений и БД под них; pod’ы могут легко переезжать между машинами).
Да, это далеко от best practice, но workaround, который на тот момент позволял добиваться желаемого (K8s в маленьких проектах) небольшими средствами. В остальных случаях применялись другие подходы.
Со временем такой подход показал нам все подводные камни — ну, может, не все, но достаточное количество, чтобы значительно его переосмыслить. И мы полностью отказались от виртуалок на Ceph’е в таких проектах, делаем Kubernetes-узлы без виртуализации и т.п.
Поскольку такая схема и без важных уточнений описана в старом докладе, пожалуй, самое время актуализировать эту информацию. Мы напишем новую статью о нынешнем видении (и реализации) Kubernetes’а для небольших проектов — чтобы другие не повторяли ошибок. Спасибо за обратную связь!
Круто, пойду почитаю, что у вас нового на выходных, раньше никак.
P.S. Про лс помню, не добрался ещё
P.S. Про лс помню, не добрался ещё
DS
Круто, пойду почитаю, что у вас нового на выходных, раньше никак.
P.S. Про лс помню, не добрался ещё
P.S. Про лс помню, не добрался ещё
А мы ещё не написали :) Но буквально час назад поставили такую задачу одной из DevOps-команд (описать текущие реалии) — ждём…