Container-Optimized OS

Container-Optimized OS або COS — це спеціалізована операційна система Google для запуску контейнерів на Google Cloud, насамперед на Compute Engine і в Google Kubernetes Engine. Вона оптимізована для Docker-контейнерів, має мінімалістичний підхід, посилені security defaults, автоматизовані оновлення й тісну інтеграцію з Google Cloud.

Container-Optimized OS не є універсальною серверною ОС на кшталт Ubuntu Server, Debian або Rocky Linux. Її головна роль — бути надійним, компактним і керованим хостом для контейнерів.

Основна ідея: Container-Optimized OS — це не “Linux для всього”, а спеціальний хмарний образ для запуску контейнерів із мінімальним зайвим навантаженням.

Цікавий факт

Container-Optimized OS базується на open source ChromiumOS project. Тобто в неї є спільне коріння з технологічною основою ChromeOS, але призначення зовсім інше: не ноутбук для користувача, а хмарна VM для контейнерів. :contentReference[oaicite:1]{index=1}

Це цікаво, бо COS показує одну з важливих ідей сучасної інфраструктури: серверна ОС не обов’язково має бути “повноцінним робочим середовищем”. Іноді найкраща ОС — це та, яку майже не чіпають руками, а просто запускають на ній контейнер.

Найцікавіше: Container-Optimized OS схожа на службовий ліфт у датацентрі: вона не створена для краси, але швидко й надійно доставляє контейнер туди, де він має працювати.

Загальний опис

Container-Optimized OS — це образ операційної системи для Google Compute Engine VM, оптимізований для запуску контейнерів. Google описує COS як спосіб швидко, ефективно й безпечно запускати Docker-контейнери на Google Cloud Platform. :contentReference[oaicite:2]{index=2}

COS використовується для:

запуску Docker-контейнерів на Compute Engine;
Kubernetes node OS у GKE;
containerized applications;
immutable infrastructure;
простих container hosts;
batch workloads;
edge-like cloud workloads;
managed instance groups;
autoscaling container workloads;
хмарних сервісів із мінімальним host management;
безпечніших container hosts;
GPU container workloads у підтримуваних сценаріях;
workloads, де не потрібна повна серверна ОС.

Перевага: COS зменшує кількість ручної роботи з сервером: замість встановлення Docker, налаштування пакетів і hardening адміністратор отримує готовий container-focused образ.

Для чого потрібна Container-Optimized OS

COS корисна там, де сервер існує не для того, щоб на ньому “жили” вручну встановлені програми, а для запуску контейнера.

Типові сценарії:

один контейнер на VM;
кілька контейнерів через container startup config;
Kubernetes node;
stateless service;
web service у контейнері;
worker service;
batch job;
CI/CD-deployed container;
autoscaled service;
application appliance;
контейнер із GPU;
sandboxed cloud workload.

Проста аналогія: звичайна Linux VM — це майстерня з купою інструментів. COS — це спеціальна платформа, де головний інструмент уже один: запуск контейнера.

Зв’язок із Google Cloud

Container-Optimized OS є продуктом Google Cloud і найкраще розкривається саме в Google Cloud-середовищі.

COS інтегрується з:

Compute Engine;
Google Kubernetes Engine;
Cloud Logging;
guest environment;
OS Config у відповідних сценаріях;
IAM;
metadata server;
managed instance groups;
instance templates;
GPU accelerators;
Google Cloud networking;
Google Cloud monitoring;
container startup configuration.

Офіційні how-to матеріали Google Cloud для COS включають створення інстансів, запуск контейнерів, AppArmor, Cloud Logging, Node Problem Detector, host firewall, GPU accelerators і user-defined guest policies. :contentReference[oaicite:3]{index=3}

Практична роль: COS варто розглядати не окремо від Google Cloud, а як частину екосистеми Compute Engine і GKE.

ChromiumOS-основа

Container-Optimized OS базується на open source ChromiumOS project. Це дає системі низку ідей, характерних для appliance-like ОС:

мінімалістичний образ;
контрольований system image;
security-focused design;
автоматичні оновлення;
read-only підхід до частини системи;
менше ручного втручання;
орієнтація на керованість;
чітка роль системи.

Важливо: COS не є ChromeOS для серверів. Вона лише базується на ChromiumOS-проєкті й адаптована Google для container workloads у Google Cloud.

Контейнери

Контейнер — це ізольоване середовище для запуску застосунку разом із його залежностями.

COS оптимізована саме для контейнерів, тому застосунок зазвичай доставляється як container image, а не встановлюється пакетами в систему.

Контейнери корисні для:

однакового запуску в різних середовищах;
швидкого deployment;
dependency isolation;
immutable application packaging;
microservices;
CI/CD;
rollback;
scaling;
Kubernetes;
cloud-native архітектури.

Практична роль: у COS застосунок має жити в контейнері, а не “розмазуватися” по файловій системі сервера.

Docker

Container-Optimized OS історично оптимізована для запуску Docker-контейнерів на Compute Engine. Офіційна документація описує COS як ОС image, optimized for running Docker containers. :contentReference[oaicite:4]{index=4}

Docker у COS використовується для:

pulling container images;
запуску контейнерів;
керування container lifecycle;
логування контейнерів;
networking;
volume mounts;
інтеграції з startup scripts;
локального тестування container behavior на VM.

Практична роль: Docker у COS — це головний шлях запуску застосунку, а не додаткова опція поверх класичного сервера.

Kubernetes і GKE

Container-Optimized OS часто використовується як node OS у Google Kubernetes Engine. Офіційна документація Google Cloud зазначає, що COS є default node OS image in Kubernetes Engine та інших Kubernetes deployments на Google Cloud Platform. :contentReference[oaicite:5]{index=5}

У GKE COS важлива для:

Kubernetes nodes;
kubelet;
container runtime;
node security;
node upgrades;
verified node images;
managed Kubernetes operations;
GKE release integration;
predictable node behavior;
container-first infrastructure.

Перевага: у GKE адміністратор часто не думає про COS напряму, але саме node OS впливає на безпеку, оновлення й стабільність Kubernetes-вузлів.

Compute Engine

COS можна використовувати напряму на Compute Engine VM.

Сценарії:

створити VM з COS image;
вказати container image;
налаштувати startup script;
підключити service account;
відкрити потрібні firewall rules;
експортувати логи;
додати VM до managed instance group;
масштабувати через instance template;
оновлювати образи через rolling update.

Практична роль: COS на Compute Engine добре підходить, коли Kubernetes зайвий, але контейнерний спосіб доставки застосунку вже зручний.

Відсутність package manager

Одна з головних особливостей COS — відсутність звичайного package manager. Офіційна документація прямо зазначає, що Container-Optimized OS does not include a package manager, тому не можна встановлювати software packages безпосередньо на instance. :contentReference[oaicite:6]{index=6}

Це зроблено не як недолік, а як частина філософії:

менше mutable state;
менше випадкових змін;
менше attack surface;
простіший образ;
краще відтворення середовища;
застосунок має бути в контейнері;
host не перетворюється на “сніжинку”.

Важливо: якщо потрібно постійно встановлювати пакети через apt або yum, COS майже напевно не той вибір.

Toolbox

Оскільки COS не має package manager, для debugging і адміністративних інструментів можна використовувати toolbox-підхід. Документація Google Cloud згадує CoreOS toolbox як спосіб встановлювати й запускати debugging/admin tools в ізольованому контейнері. :contentReference[oaicite:7]{index=7}

Toolbox корисний для:

тимчасового debug;
запуску додаткових утиліт;
мережевої діагностики;
перевірки файлової системи;
аналізу процесів;
тестування;
адміністративних задач без зміни host OS.

Практична роль: toolbox — це як тимчасовий рюкзак із інструментами: взяв для діагностики, використав, але не перетворив host на звичайний mutable server.

Locked-down kernel

COS має locked-down kernel. Офіційна документація зазначає, що користувач не може встановлювати third-party kernel modules або drivers. :contentReference[oaicite:8]{index=8}

Це важливо для:

security hardening;
передбачуваності;
стабільності;
керованих оновлень;
зменшення kernel attack surface;
зниження ризику несумісних драйверів;
стандартизованого cloud image.

Критично: якщо workload потребує custom kernel module, нестандартного драйвера або глибокої зміни kernel, Container-Optimized OS не підходить.

Non-containerized applications

COS не призначена для запуску non-containerized applications. Google Cloud прямо зазначає, що Container-Optimized OS does not support execution of non-containerized applications. :contentReference[oaicite:9]{index=9}

Це означає:

застосунки мають бути в контейнерах;
не потрібно встановлювати app напряму на host;
системні зміни мають бути мінімальними;
host OS не використовується як звичайний Linux server;
dependency management переноситься в container image.

Правило: якщо програма не контейнеризована й потребує класичної інсталяції в ОС, краще обрати інший Linux image.

Security hardening

COS має security-focused підхід для container host.

Типові security-ідеї:

мінімальна система;
locked-down kernel;
відсутність package manager;
контрольований образ;
container isolation;
AppArmor;
інтеграція з Google Cloud IAM;
автоматичні оновлення;
менше фонових сервісів;
зменшена attack surface;
read-only системні частини;
кероване логування.

Google Cloud рекомендує COS, якщо потрібна ОС із small footprint і security hardened for containers. :contentReference[oaicite:10]{index=10}

Головна перевага: COS зменшує кількість речей, які адміністратор може випадково встановити, забути оновити або неправильно налаштувати.

AppArmor

Container-Optimized OS підтримує сценарії захисту контейнерів через AppArmor. У Google Cloud документації є окремий how-to розділ про securing containers with AppArmor. :contentReference[oaicite:11]{index=11}

AppArmor може допомагати:

обмежувати доступ контейнерів;
зменшувати наслідки compromise;
описувати security profiles;
контролювати файлові й системні операції;
робити defense-in-depth;
посилювати container isolation.

Критично: контейнер — це не абсолютна межа безпеки. AppArmor, least privilege, non-root containers і правильні IAM-права все одно потрібні.

Cloud Logging

COS може інтегруватися з Cloud Logging для експорту системних і container logs. Google Cloud має окремий how-to про використання Cloud Logging із Container-Optimized OS. :contentReference[oaicite:12]{index=12}

Cloud Logging корисний для:

centralized logs;
container logs;
system logs;
troubleshooting;
audit;
monitoring;
alerting;
incident response;
fleet visibility;
debugging autoscaled workloads.

Практична роль: у контейнерній інфраструктурі логи не мають залишатися лише на VM, бо VM може бути пересоздана або видалена.

Fluent Bit

У release notes COS згадується перехід до нового logging agent fluent-bit: milestone 105 ввів fluent-bit як optional logging agent, який мав стати default logging agent у майбутніх milestones. :contentReference[oaicite:13]{index=13}

Fluent Bit важливий для:

легкого збору логів;
container logs;
forwarding;
cloud logging;
менших ресурсів;
observability;
node-level logging.

Цікавий момент: у container host логування — це не дрібниця, а частина архітектури. Без правильного log forwarding контейнер може “зникнути” разом зі своїми слідами.

Node Problem Detector

Google Cloud має how-to про monitoring system health with Node Problem Detector на COS. :contentReference[oaicite:14]{index=14}

Node Problem Detector використовується для:

виявлення проблем вузла;
kernel issues;
container runtime problems;
filesystem problems;
system health monitoring;
Kubernetes node diagnostics;
alerting;
observability;
зменшення часу пошуку причин інцидентів.

Практична роль: Node Problem Detector допомагає не просто бачити, що контейнер упав, а помічати, що проблема може бути на рівні вузла.

GPU accelerators

COS підтримує запуск інстансів із GPU accelerators у відповідних сценаріях. Google Cloud має окремий how-to про running instances with GPU accelerators на COS. :contentReference[oaicite:15]{index=15}

GPU-сценарії:

ML inference у контейнері;
video processing;
batch compute;
rendering;
GPU-enabled workloads;
containerized AI services;
data processing.

Важливо: GPU на COS потрібно налаштовувати за документацією Google Cloud, бо драйвери й runtime мають відповідати образу, GPU і container workload.

Host firewall

COS підтримує налаштування host firewall. У документації Google Cloud є окремий how-to про configuring the host firewall for Container-Optimized OS. :contentReference[oaicite:16]{index=16}

Firewall важливий для:

обмеження inbound traffic;
захисту host;
контролю доступу до container ports;
defense-in-depth;
локальних правил;
segmentation;
додаткового захисту поверх Google Cloud firewall rules.

Правило: Google Cloud firewall і host firewall потрібно проєктувати разом, а не як два випадкові незалежні набори правил.

Automatic updates

COS підтримує керовані оновлення образу й життєвий цикл релізів. Release notes Google Cloud містять актуальні milestones, changelogs, kernel, Kubernetes і Docker/container-related компоненти для конкретних COS image. :contentReference[oaicite:17]{index=17}

Оновлення важливі для:

security patches;
container runtime fixes;
kernel fixes;
logging agent changes;
Kubernetes node compatibility;
GPU support;
bug fixes;
Google Cloud guest environment;
production stability.

Критично: навіть container host потрібно оновлювати. Контейнери не скасовують security patches для kernel і host OS.

Release channels і milestones

Container-Optimized OS має релізи й milestones, які публікуються в Google Cloud release notes. У release notes є таблиці доступних COS releases для Compute Engine. :contentReference[oaicite:18]{index=18}

Для production важливо контролювати:

milestone;
LTS-статус;
image family;
kernel version;
container runtime version;
Kubernetes-related components;
security updates;
end of support;
upgrade path;
compatibility with GKE або Compute Engine workload.

Важливо: не варто прив’язувати production до випадкового старого COS image. Потрібно планувати image updates і перевіряти release notes.

Immutable infrastructure

COS добре вписується в підхід immutable infrastructure.

Це означає:

не налаштовувати сервер вручну;
не встановлювати пакети на live VM;
зберігати застосунок у container image;
оновлювати через новий image;
пересоздавати VM замість ручного ремонту;
використовувати instance templates;
робити rolling updates;
не тримати важливий state на host.

Проста аналогія: mutable server — це зошит із виправленнями ручкою. Immutable server — це надрукований аркуш: якщо потрібна зміна, друкують нову версію.

Stateless workloads

COS найкраще підходить для stateless або добре спроєктованих stateful-сценаріїв.

Stateless workload:

не зберігає важливі дані на локальному диску;
може бути пересозданий;
масштабується горизонтально;
бере конфігурацію з metadata, env або secret manager;
пише логи назовні;
зберігає дані в managed database, object storage або persistent volume.

Практична роль: COS найкраще працює, коли VM можна видалити й створити заново без втрати бізнес-даних.

Stateful workloads

Stateful workloads на COS можливі, але потребують обережності.

Потрібно продумати:

persistent disks;
backups;
filesystem consistency;
graceful shutdown;
container volumes;
data migration;
recovery;
snapshot policy;
monitoring;
update strategy;
disaster recovery.

Критично: контейнер не є backup. Якщо workload має дані, потрібні persistent storage, backup і перевірений restore.

COS і Ubuntu Server

Критерій	Container-Optimized OS	Ubuntu Server
Основна роль	Container host для Google Cloud	Універсальна серверна ОС
Package manager	Немає звичайного package manager	apt
Non-container apps	Не підтримуються як основний сценарій	Підтримуються
Kernel customization	Обмежена, locked-down kernel	Значно гнучкіша
Найкраще для	Docker/Kubernetes workloads на GCP	Загальні серверні задачі

Висновок: COS краще для чистих container workloads у Google Cloud, а Ubuntu Server — для випадків, де потрібна повноцінна Linux-система з пакетами й ручною кастомізацією.

COS і Debian

Критерій	Container-Optimized OS	Debian
Тип	Спеціалізований cloud container OS image	Універсальний Linux-дистрибутив
Адміністрування	Мінімальне host management	Повне адміністрування ОС
Пакети	Немає package manager	apt/dpkg
Безпека	Hardened для контейнерів	Залежить від конфігурації
Сценарій	Запуск контейнера як основна задача	Сервери, застосунки, бази, services

Висновок: Debian краще для класичного Linux-сервера, а COS — для спеціального container host у Google Cloud.

COS і Bottlerocket

Bottlerocket — container-focused OS від AWS. COS і Bottlerocket схожі ідеєю: мінімальна ОС для контейнерів у хмарі.

Критерій	Container-Optimized OS	Bottlerocket
Вендор	Google	AWS
Основне середовище	Google Cloud, GKE, Compute Engine	AWS, EKS, ECS
Фокус	Container workloads на GCP	Container workloads на AWS
Підхід	Мінімальний hardened image	Мінімальна container OS з API-driven management

Висновок: COS — природний вибір у Google Cloud, Bottlerocket — в AWS-середовищах.

COS і Flatcar Container Linux

Flatcar Container Linux — ще одна container-focused Linux-система, яка продовжує ідеї CoreOS Container Linux.

Критерій	Container-Optimized OS	Flatcar Container Linux
Основна екосистема	Google Cloud	Multi-cloud/self-managed container infrastructure
Підтримка	Google	Flatcar ecosystem
Типовий сценарій	Compute Engine, GKE	Kubernetes nodes, self-managed clusters
Кастомізація	Обмежена, GCP-focused	Більш гнучка для різних середовищ

Висновок: COS зручна для Google Cloud-native сценаріїв, а Flatcar може бути цікавішою для multi-cloud або self-managed container hosts.

Переваги Container-Optimized OS

Основні переваги COS:

оптимізація для контейнерів;
підтримка Google;
інтеграція з Compute Engine;
інтеграція з GKE;
базується на ChromiumOS project;
small footprint;
security hardening;
відсутність package manager як спосіб зменшити mutable state;
locked-down kernel;
AppArmor;
Cloud Logging;
Node Problem Detector;
GPU-сценарії;
менше ручного адміністрування;
хороша відповідність immutable infrastructure;
зручність для autoscaling workloads.

Головна перевага: COS робить container host простішим і передбачуванішим: менше зайвого в ОС, більше уваги до контейнера.

Обмеження Container-Optimized OS

COS має обмеження.

Можливі проблеми:

немає package manager;
не підтримує non-containerized applications;
locked-down kernel;
не можна встановлювати third-party kernel modules;
не підходить для сильно кастомних Linux-серверів;
прив’язана до Google Cloud-сценаріїв;
debugging може вимагати toolbox;
не підходить для legacy apps;
не найкращий вибір для stateful workloads без правильної архітектури;
менше свободи, ніж у стандартному Linux-дистрибутиві;
потрібно стежити за release milestones і image lifecycle.

Помилка: обирати COS, а потім намагатися поводитися з нею як із Ubuntu Server: ставити пакети, змінювати host, запускати неконтейнерні служби й вручну “лікувати” VM.

Коли варто використовувати COS

Container-Optimized OS добре підходить, якщо потрібно:

запускати Docker containers на Compute Engine;
використовувати GKE node OS;
мінімізувати host management;
побудувати immutable infrastructure;
запускати stateless services;
швидко підняти containerized app;
використовувати managed instance groups;
зменшити attack surface;
мати Google-maintained container OS;
працювати в Google Cloud;
запускати container workload без повного Kubernetes;
мати standardized container host.

Практична порада: COS варто обирати, коли застосунок уже контейнеризований і вся логіка deployment побудована навколо container image.

Коли COS може бути невдалим вибором

COS може бути не найкращим вибором, якщо:

потрібно встановлювати пакети через apt/yum;
застосунок не контейнеризований;
потрібні custom kernel modules;
потрібні нестандартні драйвери;
сервер має багато ручних служб;
потрібен класичний Linux admin workflow;
workload сильно stateful без продуманого storage;
потрібна повна свобода дистрибутива;
команда не готова до immutable/container-first підходу;
інфраструктура не в Google Cloud.

Важливо: COS найкраща тоді, коли ви приймаєте її обмеження як частину дизайну, а не боретеся з ними.

Хороші практики COS

Рекомендовано:

тримати застосунок у container image;
не встановлювати програми на host;
використовувати instance templates;
робити rolling updates;
експортувати логи в Cloud Logging;
не зберігати важливі дані на ephemeral host filesystem;
використовувати persistent disk для stateful data;
налаштувати health checks;
використовувати least privilege service accounts;
запускати контейнери не від root, якщо можливо;
обмежувати container capabilities;
використовувати AppArmor;
стежити за release notes;
планувати оновлення image family;
використовувати Node Problem Detector у Kubernetes-сценаріях;
тестувати startup scripts і container configs.

Головне правило: COS-хост має бути одноразовим і відтворюваним. Якщо VM шкода видалити, архітектура, ймовірно, занадто mutable.

Типові помилки початківців

Поширені помилки:

шукати apt або yum;
встановлювати інструменти напряму на host;
запускати застосунок без контейнера;
писати логи тільки на локальний диск;
зберігати дані всередині container filesystem;
не налаштувати restart policy;
не читати release notes;
не оновлювати COS image;
давати VM занадто широкі IAM-права;
запускати container як root без потреби;
відкривати зайві firewall ports;
не мати health checks;
намагатися встановити custom kernel module;
плутати container image update і OS image update.

Небезпека: контейнерна інфраструктура часто ламається не через сам контейнер, а через неправильні IAM-права, логи, storage, firewall або update strategy.

Цікаві факти про Container-Optimized OS

COS базується на ChromiumOS project, але створена для cloud container workloads, а не для користувацьких ноутбуків. :contentReference[oaicite:19]{index=19}
COS не має звичного package manager — це не випадковість, а спосіб зробити host більш контрольованим. :contentReference[oaicite:20]{index=20}
COS використовується як default node OS image у GKE, тому багато Kubernetes-користувачів працюють із нею непрямо. :contentReference[oaicite:21]{index=21}
У COS debugging часто робиться через toolbox-контейнер, а не через встановлення пакетів у host OS.
COS добре показує ідею “pets vs cattle”: VM не потрібно лікувати вручну, її краще пересоздати з правильного image.
У container-first світі host OS стає менш помітною, але від неї все одно залежить kernel security, logging, networking і runtime.
COS — хороший приклад того, як хмарна ОС може бути спеціалізованою, а не універсальною.

Найлюдяніший факт: COS — це ОС, яка ніби каже адміністратору: “Не прикрашай мене, не встановлюй зайвого, просто дай мені контейнер і нормальну конфігурацію”.

Приклади сценаріїв використання

Один контейнер на Compute Engine

Команда має web service у Docker image й запускає його на COS VM без повного Kubernetes.

Managed Instance Group

Сервіс запускається на кількох COS VM через instance template, health checks і autoscaling.

GKE node

Kubernetes cluster використовує COS як node OS, а користувач керує переважно pods, deployments і services.

GPU inference container

ML inference service запускається в контейнері на COS VM з GPU accelerator у підтримуваному Google Cloud-сценарії.

Batch worker

COS VM стартує, запускає containerized worker, обробляє задачу й завершується.

Підказка: якщо весь deployment можна описати як “запусти цей container image із цими env vars і цими volumes”, COS може бути дуже доречною.

Приклад запуску контейнера на COS

Спрощена ідея запуску контейнера на COS VM:

docker run -d \
  --name app \
  --restart=always \
  -p 80:8080 \
  gcr.io/example-project/example-app:latest

У production зазвичай краще використовувати instance templates, metadata, startup scripts, health checks, logging і pinned image tags або digests.

Важливо: тег `latest` зручний для прикладу, але в production краще використовувати конкретну версію або image digest.

Приклад container-first підходу

Source code
Build container image
Push image to registry
Create or update instance template
Roll out new COS VMs
Export logs to Cloud Logging
Monitor health checks
Rollback if needed

Практична роль: COS добре працює, коли deployment pipeline оновлює образи й VM, а не змінює сервери вручну.

Джерела

Google Cloud Container-Optimized OS documentation.
Container-Optimized OS overview.
Container-Optimized OS release notes.
Google Cloud documentation about creating and configuring COS instances.
Google Cloud documentation about running containers on COS.
Google Cloud documentation about AppArmor on COS.
Google Cloud documentation about Cloud Logging with COS.
Google Cloud documentation about Node Problem Detector.
Google Cloud documentation about GPU accelerators on COS.
Документація Google Kubernetes Engine щодо node images і Kubernetes nodes.

Висновок

Container-Optimized OS — це спеціалізована операційна система Google Cloud для запуску контейнерів на Compute Engine і в Kubernetes/GKE-сценаріях. Вона підтримується Google, базується на ChromiumOS project, оптимізована для Docker-контейнерів, має small footprint, security hardening, locked-down kernel, інтеграцію з Google Cloud і не має звичного package manager.

COS найкраще підходить для container-first архітектури: stateless services, managed instance groups, GKE nodes, batch workers і workloads, де VM є відтворюваним container host. Водночас COS не підходить для класичних серверів із ручним встановленням пакетів, non-containerized apps, custom kernel modules або legacy workloads.

Головна думка: Container-Optimized OS — це ОС для епохи контейнерів: менше ручного адміністрування host, більше дисципліни в container image, deployment pipeline, logging, security і оновленнях.