Stanislav Pugachev

Ivan Yakushenko,

https://aiohttp.readthedocs.io/en/stable/client_qu...

myasnik8352
вот такое еще есть https://kubernetes.io/docs/concepts/containers/con...

https://kubernetes.io/docs/concepts/workloads/pods...
Более конкретней: https://kubernetes.io/docs/tasks/access-applicatio...

проще наверное от обратного тут

s = 1 + 2
s = (1 + 2)
s = (
   1 + 2
)
s = (
   1
   +
   2
)

все эти операции по сути одно и тоже
скобки часто объюзят как в последнем примере потому что так удобно записывать операции растянутые на несколько строк

то есть применительно конкретно к вашему вопросу мы имеем все тоже самое но в обратную сторону

s = (
    "Привет"
    "Мир"
) 
s = ("Привет" "Мир")
s = "Привет" "Мир" // что есть обычной конкатенацией в питоне

если непонятно почему опускаются скобки - то это просто потому что они ничего по сути не группируют
в моем примере будет

s = (1 + 2)
s = (3)  // какой смыл тут от скобок?

в вашем примере тоже самое
вначале произойдет конкатенация и скобки примененные к одному операнду как бы опустятся за неимением большого в этом смысла

gremlintv2,

вообще чисто идеологически prometheus работает через pull данных
но, бывает так что сущности которые мы собираемся мониторить:
1) являются эфемерными, то есть, являются смертными сущностями, которые могут восстать позже, в другом месте и с другим адресом например
2) могут быть просто job'ами которые естественно живут какой-то определенный промежуток времени
3) просто не доступны для prometheus сервера

Хороших вариантов на самом деле 2 как по мне
1) если промитеус сидит внутри того же кластера - то мы просто добавляем в конфиг секцию типа такой

job_name: ${appName}
kubernetes_sd_configs:
- role: pod
relabel_configs:
- action: keep
  regex: ${appName}
  source_labels:
  - __meta_kubernetes_pod_container_name
metrics_path: ${path}
scrape_interval: ${interval}s

тогда промитеус через нативный кубернет DNS сможет получить информацию о подах, отфильтрует по __meta_kubernetes_pod_container_name все нужные и все будет заебись

2) этот вариант подойдет для обоих вариантов когда промитеус сидит внутри или снаружи кластера
https://github.com/prometheus/pushgateway
если вкратце то 1) вы создаете пушгейтвей эндпоинт для вашего сервиса, 2) туда по хттп пушите свои метрики 3) в конфиге промитеус-сервер вы добавляете `scrape_configs` секцию как обычно, которая пулит данные с пушгейтвей эндпоинта

PS
node_exporter в этом случае не особо помогает потому что по сути создает эндпоинт который должен мониторить промитеус, если само приложение не доступон для промитеуса то и node_exporter тоже не будет доступен что очевидно

vlarkanov,

по-моему этот вопрос уже задавали когда-то
суть в том что когда вы выполняете команду "в консоли" вы по факту используете bash скорее всего или его производные
cron же в свою очередь использует sh, а не bash
а там есть небольшие нюансы в написании команд

weranda,

https://pypi.org/project/fuzzywuzzy/0.3.0/

https://en.wikipedia.org/wiki/Alpine_Linux

The base system in Alpine Linux is designed to be only 4–5 MB in size (excluding the kernel).[citation needed] This allows very small Linux containers, around 8 MB in size, while a minimal installation to disk might be around 130 MB.

вопросы у вас философские, на каждый можно отвести часы обсуждения

Полноценный CI/CD поднимать не вижу смысла ввиду размеров

вы ж все равно собираетесь какие-то скрипты мутить и чото выдумывать,
какая разница это будут крон скрипты на сервере или джоба в дженкинсе? по-скорости написания - одно и тоже будет. так что по-моему размер тут не имеет значение
единственное что имеет значение - насколько явно у вас описан процесс(алгоритм) билда/разворачивания приложений
с этой точки зрения мое видение примерно такое:

1) git не есть инструмент для развертывания по, git лишь для версионирования кода
и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
Артефакты желательно хранить в каком-то артефактории,
но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

2) как только вы получили артефакт - его можно деплоить
неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

В чем еще преимущество такого подхода: если вам нужно сделать roll-back на предыдущую версию вам не нужно собирать проект заново выкачивая все с гита, ведь у вас есть предыдущие артефакты, ролбек в таком случае вообще не проблема - просто указываем предыдущую версию артефакта и деплоим еще раз и все

3) Env Variables
когда приложение стартует - считывает все что ему нужно из переменных окружения
деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

Итого имеем
- логика сборки проекта описана в Dockerfile и находится под гитом
- логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
- на сервере мы ничего не устанавливали совершенно кроме самого докера
- мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
- сервер не знает ничего о гитах
- на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
- имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)