docker events
) и выгружать из journald по имени, которым её назовёте.[Unit]
Description=Docker OOM Monitor Service
[Service]
Type=simple
ExecStart=/usr/bin/docker events --filter type=oom
[Install]
WantedBy=multi-user.target
Для примера, предположим, что есть (сферический в вакууме) CRUD сервис ... Предположим, что точная оценка не требуется. Даже погрешность в несколько раз будет приемлемой.Сервисов в вакууме не бывает, разный код и внешние зависимости будут влиять по-разному на использование ресурсов с разбегом в несколько порядков.
Например, для оценки latency существуют подобные таблицыПутаете физику с лирикой. В приведённой вами таблице значения вырастают из физических и технических ограничений.
resource "aws_launch_configuration" "myapp" {
name_prefix = "myapp_"
...
resource "aws_autoscaling_group" "myapp" {
name = "myapp - ${aws_launch_configuration.myapp.name}"
min_elb_capacity = = "${var.myapp_asg_min_size}"
...
lifecycle { create_before_destroy = true }
min_elb_capacity
, они не будут прицеплены к балансировщику. Затем уже сам балансировщик по хелсчекам у себя должен поменять статус новым инстансам как InService и начнёт пускать на них трафик, в этот же момент TF начнёт удалять старую ASG. хочу закрепить его с lpic-1Всем как всегда. LPIC-1 слишком поверхностный и покрывает совсем базовые навыки, которые безусловно необходимы, но не достаточны для полноценной работы админом.
Опыт в сфере ИБСлабо релевантно
Опыт в ит менеджменте, есть itilСовсем не релевантно.
жуниером найти работу на удаленкуНевозможно
можно даже на пол ставки чтобы набраться опыта?Невозможно [2]
При этом хотелось бы избежать велосипедов с шелл-скриптами и прочим подобным. Докер же должен предоставлять что-то из коробки - вроде бы стандартная хотелка, не так уж и много, а как сделать - не нашел, и судя по всему, будет лютый костыль.Велосипед - это когда что-то готовое уже есть. Докер никому ничего не должен, кроме обратной совместимости и фикса багов. Про "не так уж и много" - напишите и сделайте pull request, ссылку только сюда приложить не забудьте. Костыль будет ровно таким, каким вы его напишите.
ES_URL='http://elasticsearch_address:port' #URL эластика
ATTR_NAME="storage_type" #аттрибут ноды, устанавливается в elasticsearch.yml
ATTR_WARM="hdd" #значение аттрибута, соответствующий "тёплой" ноде
N=3 #количество календарных дней до передвижения индекса
END_DATE=$(date --date="$N days ago" -I)
for INDEX in $(curl -s "$ES_URL"'/_cat/indices?h=index,creation.date.string&format=json' |
jq -rc '.[] | select(."creation.date.string" < "3*") | .index')
do
curl -s -XPUT "${ES_URL}/${INDEX}/_settings" -d "{\"index.routing.allocation.require.${ATTR_NAME}\":\"{ATTR_WARM}\"}"
if [ $& -eq]
then
echo "$INDEX has been set up"
else
echo "Error while setting up $INDEX"
ERRORS=
fi
done
if [[ -v $ERRORS ]]
then
exit 1
fi
Но до сих пор не имею представления, какой инструментарий используют профессиональные DevOps на своих Kubernetis-кластерах для этих целей.Архитектура метрик и их обработки в k8s. Как правило для унификации используют Prometheus т.к. под него уже многое заточено в самом кубере.
docker tag image_id $registry_addr/$image_name:"$BUILD_NUMBER"
docker push $registry_addr/$image_name:"$BUILD_NUMBER"