Всем привет! Меня зовут Тамара, я работаю в Тинькофф и отвечаю за торговый эквайринг и онлайн-кассы.
Недавно на рынке появился новый способ оплаты покупок — по QR-коду через Систему быстрых платежей (СБП). Однако пока в сети мало информации о том, как все работает. В этой статье я подробно расскажу, как это выглядит со стороны продавца и как — со стороны клиента.

Что такое СБП

Мы все привыкли к переводам денег по номеру карты и покупкам по карте. Но за проведение таких операций Visa и Mastercard берут с банков солидные комиссии. Поэтому Банк России создал альтернативный сервис для перевода денег со счета на счет — Систему быстрых платежей (СБП).

Как это работает

Перевод средств между счетами физических лиц по СБП практически не отличается от обычного перевода по карте. Отправитель указывает номер телефона получателя — и деньги отправляются по назначению.
При оплате товара через СБП деньги переводятся со счета физического лица (покупателя) на счет юридического лица (продавца). Чтобы оплатить покупку, нужно отсканировать специальный QR-код. Он может быть двух видов: статический или динамический. Про них мы расскажем ниже.
Итак, покупатель сканирует QR-код, подтверждает оплату в приложении — и деньги зачисляются на счет продавца. Кстати, деньги приходят на счет мгновенно (поэтому платежи и зовутся быстрыми).
Дальше будем говорить именно об оплате покупок с помощью СБП.

Сколько это стоит

Банк России создал СБП для того, чтобы уменьшить финансовую нагрузку на торговые точки: ведь магазины платят за возможность принимать деньги от людей через терминал. Комиссия по СБП не должна быть выше определенного значения, которое существенно ниже комиссии по «обычному» эквайрингу. Это и привлекает клиентов, ведь все хотят сэкономить.
Максимальное значение комиссии определяется в зависимости от вида деятельности компании.
Государственные платежи – без комиссии.
Льготные категории – 0,4%:

• Оплата услуг медицинских и образовательных учреждений
• Платежи в пользу благотворительных организаций
• Оплата жилищно-коммунальных услуг
• Оплата услуг транспортной инфраструктуры
• Оплата телекоммуникационных, информационных и почтовых услуг
• Оплата потребительских товаров и товаров повседневного спроса
• Оплата лекарств, БАД и иных товаров медицинского назначения, исключая медтехнику
• Оплата услуг страховых компаний
• Перевод денежных средств на счета профессиональных участников рынка ценных бумаг и управляющих компаний инвестиционных фондов, паевых инвестиционных фондов и негосударственных пенсионных фондов

Остальные виды деятельности – 0,7%.
За возврат платежа комиссия не взимается. Актуальные тарифы ЦБ.

Статический QR-код

Статический QR-код — это просто картинка, которую продавец распечатывает и наклеивает рядом с кассовой зоной или сохраняет в телефоне, планшете или ноутбуке. Такой QR-код присваивается единожды расчетному счету клиента и больше не меняется.
Процесс оплаты в этом случае выглядит так:

1. Продавец считает, сколько денег ему должен покупатель за весь товар.
2. Покупатель сканирует QR-код телефоном.
3. При сканировании открывается мобильное приложение банка — участника СБП.
4. Покупатель указывает сумму, которую необходимо перевести за товар.
5. Покупатель подтверждает оплату — и деньги переводятся на счет продавца.
6. Продавец проверяет факт оплаты (например, проверяет операции по счету). Теперь он может отдать товар.

Обычно такой способ оплаты выбирают клиенты с небольшим потоком покупателей. Процесс оплаты небыстрый: покупателю нужно самому вводить сумму перевода, а продавцу как-то проверять, что деньги, которые поступили на счет, пришли именно от этого покупателя. Основное преимущество статического QR-кода в том, что для него не нужно никакое оборудование. Можно просто распечатать и повесить на стену наклейку и начать принимать безналичные платежи.

Динамический QR-код

Динамический QR-код, в отличие от статического, при каждой операции создается заново. Он уже содержит в себе информацию о сумме проводимой операции (то есть сколько покупатель должен заплатить). Его применяют при оплате в интернет-магазине, на терминале, на кассе, в приложении курьера.
С динамическим QR-кодом процесс оплаты становится проще. Для торговой точки он выглядит так:

1. Продавец считает, сколько денег ему должен покупатель за весь товар, и указывает нужную сумму на кассе или терминале.
2. На кассе или терминале выводится QR-код, который уже содержит в себе информацию о сумме, которую необходимо заплатить.
3. Покупатель сканирует QR-код.
4. При сканировании открывается приложение.
5. Покупатель подтверждает оплату.
6. Деньги приходят на счет продавца.
7. Продавец получает уведомление, что покупка успешно оплачена. Теперь он может отдать товар.

Аналогично процесс выглядит для курьера. В этом случае вместо продавца выступает курьер, а QR-код выводится в курьерском приложении. Для интернет-магазинов все еще проще: QR-код создается автоматически при оплате заказа.
Динамический QR-код удобнее в работе, чем статический, так как в нем уже зашита информация о сумме покупки, а значит, процесс оплаты происходит быстрее: покупателю не нужно совершать лишнее действие. С другой стороны, придется потратить время на поиск программного обеспечения, поддерживающего оплату по СБП, а затем на его настройку. Поэтому динамический QR-код подходит более крупным клиентам, которым важно, чтобы оплата производилась довольно быстро.

Не вместо эквайринга, а вместе с эквайрингом

СБП — хороший способ сэкономить. Но, используя только СБП, без обычного эквайринга, клиент накладывает на себя ограничения, которые могут отрицательно повлиять на прибыль.
Если клиент хочет сэкономить с помощью СБП, мы не рекомендуем игнорировать «классический» способ приема платежей — через терминал.

Платить по СБП могут не все покупатели

Провести оплату таким способом покупатель может, только если он является клиентом банка, подключенного к СБП. Актуальный список банков-участников можно посмотреть на сайте СБП.
Например, клиенты Тинькофф могут свободно платить через СБП. Но, если банк к СБП не подключен, произвести оплату по СБП не получится. Проверить, могут ли клиенты конкретного банка оплатить покупку по СБП, можно на сайте СБП – около названия банка будет указано “Оплата по QR”.

Без телефона с камерой — никак

Даже если покупатель является клиентом банка — участника СБП, у него может не быть мобильного телефона с камерой для сканирования или мобильного банка на телефоне. Ему может быть просто неудобно так платить. И тогда он уйдет.

Никакого кэшбэка

При оплате по СБП покупатель не получает кэшбэк (ведь кэшбэк платится из комиссии, которую платит продавец банку). Он предпочтет конкурента, у которого можно заплатить картой и получить кэшбэк.

Хочешь купить — заплати комиссию

Операция по СБП — это перевод со счета на счет. При оплате по кредитной карте покупатель не только не получит кэшбэк, но еще и заплатит комиссию за перевод с кредитного счета. Если клиент не может или не хочет платить дебетовой картой, он уйдет.

Это до-о-олго!

Даже если покупатель согласен оплатить покупку через СБП, весь процесс занимает куда больше времени, чем просто приложить карту к терминалу. Это приводит к очередям, что невыгодно сказывается на прибыли.

Большую покупку не оплатишь

Операции больше 600 тысяч рублей проводить по СБП нельзя.

Что еще?

Нужно понимать, что, даже если покупатель в первый раз оплатит товар таким способом, не факт, что в следующий раз он вернется. Может не захотеть повторить опыт.
На подмогу СБП придет эквайринг на терминале, который хоть и дороже, зато позволит принять платеж там, где не справился СБП. Для оплаты по терминалу не нужен мобильный телефон последней модели с установленным мобильным банком. Не нужно быть клиентом какого-то конкретного банка. Покупатель сможет провести оплату на любую сумму, при этом получит кэшбэк и не заплатит комиссию. А покупку можно провести за пару секунд, просто приложив карту к терминалу.

Перевод статьи подготовлен в преддверии старта курса «DevOps практики и инструменты».

---

Если вы это читаете, вероятно, вы что-то слышали о Kubernetes (а если нет, то как вы здесь оказались?) Но что же на самом деле представляет собой Kubernetes? Это “Оркестрация контейнеров промышленного уровня”? Или «Cloud-Native Operating System»? Что вообще это значит?

Честно говоря, я не уверен на 100%. Но думаю интересно покопаться во внутренностях и посмотреть, что на самом деле происходит в Kubernetes под его многими слоями абстракций. Так что ради интереса, давайте посмотрим, как на самом деле выглядит минимальный “кластер Kubernetes”. (Это будет намного проще, чем Kubernetes The Hard Way.)

Я полагаю, что у вас есть базовые знания Kubernetes, Linux и контейнеров. Все, о чем мы здесь будем говорить предназначено только для исследования/изучения, не запускайте ничего из этого в продакшене!

Обзор

Kubernetes содержит много компонент. Согласно википедии, архитектура выглядит следующим образом:

Здесь показано, по крайней мере, восемь компонент, но большинство из них мы проигнорируем. Я хочу заявить, что минимальная вещь, которую можно обоснованно назвать Kubernetes, состоит из трех основных компонент:

• kubelet
• kube-apiserver (который зависит от etcd — его базы данных)
• среда выполнения контейнера (в данном случае Docker)

Давайте посмотрим, что о каждом из них говорится в документации (рус., англ.). Сначала kubelet:

Агент, работающий на каждом узле в кластере. Он следит за тем, чтобы контейнеры были запущены в поде.

Звучит достаточно просто. Что насчет среды выполнения контейнеров (container runtime)?

Среда выполнения контейнера — это программа, предназначенная для выполнения контейнеров.

Очень информативно. Но если вы знакомы с Docker, то у вас должно быть общее представление о том, что он делает. (Детали разделения ответственностей между средой выполнения контейнеров и kubelet на самом деле довольно тонкие и здесь я не буду в них углубляться.)

И API-сервер?

Сервер API — компонент Kubernetes панели управления, который представляет API Kubernetes. API-сервер — это клиентская часть панели управления Kubernetes

Любому, кто когда-либо что-либо делал с Kubernetes, приходилось взаимодействовать с API либо напрямую, либо через kubectl. Это сердце того, что делает Kubernetes Kubernetes’ом — мозг, превращающий горы YAML, который мы все знаем и любим (?), в работающую инфраструктуру. Кажется очевидным, что API должен присутствовать в нашей минимальной конфигурации.

Предварительные условия

• Виртуальная или физическая машина Linux с root-доступом (я использую Ubuntu 18.04 на виртуальной машине).
• И это все!

Скучная установка

На машину, которую мы будем использовать необходимо установить Docker. (Я не собираюсь подробно рассказывать как работает Docker и контейнеры; если вам интересно, есть замечательные статьи). Давайте просто установим его с помощью apt:

$ sudo apt install docker.io $ sudo systemctl start docker

После этого нам нужно получить бинарники Kubernetes. На самом деле для начального запуска нашего “кластера” нам нужен только kubelet, так как для запуска других серверных компонент мы сможем использовать kubelet. Для взаимодействия с нашим кластером после того как он заработает, мы также будем использовать kubectl.

$ curl -L https://dl.k8s.io/v1.18.5/kubernetes-server-linux-amd64.tar.gz > server.tar.gz $ tar xzvf server.tar.gz $ cp kubernetes/server/bin/kubelet . $ cp kubernetes/server/bin/kubectl . $ ./kubelet --version Kubernetes v1.18.5

Что произойдет, если мы просто запустим kubelet?

$ ./kubelet F0609 04:03:29.105194    4583 server.go:254] mkdir /var/lib/kubelet: permission denied

kubelet должен работать от root. Достаточно логично, так как ему надо управлять всем узлом. Давайте посмотрим на его параметры:

$ ./kubelet -h <слишком много строк, чтобы разместить здесь> $ ./kubelet -h | wc -l 284

Ого, как много опций! К счастью, нам понадобится только пара из них. Вот один из параметров, который нам интересен:

--pod-manifest-path string

Путь к каталогу, содержащему файлы для статических подов, или путь к файлу с описанием статических подов. Файлы, начинающиеся с точек, игнорируются. (УСТАРЕЛО: этот параметр следует устанавливать в конфигурационном файле, передаваемом в Kubelet через опцию —config. Для дополнительной информации см. kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file .)

Этот параметр позволяет нам запускать статические поды — поды, которые не управляются через Kubernetes API. Статические поды используются редко, но они очень удобны для быстрого поднятия кластера, а это именно то, что нам нужно. Мы проигнорируем это громкое предупреждение (опять же, не запускайте это в проде!) и посмотрим, сможем ли мы запустить под.

Сначала мы создадим каталог для статических подов и запустим kubelet:

$ mkdir pods $ sudo ./kubelet --pod-manifest-path=pods

Затем в другом терминале/окне tmux/еще где-то, мы создадим манифест пода:

$ cat <<EOF > pods/hello.yaml apiVersion: v1 kind: Pod metadata:   name: hello spec:   containers:   - image: busybox     name: hello     command: ["echo", "hello world!"] EOF

kubelet начинает писать какие-то предупреждения и кажется, что ничего не происходит. Но это не так! Давайте посмотрим на Docker:

$ sudo docker ps -a CONTAINER ID        IMAGE                  COMMAND                 CREATED             STATUS                      PORTS               NAMES 8c8a35e26663        busybox                "echo 'hello world!'"   36 seconds ago      Exited (0) 36 seconds ago                       k8s_hello_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_4 68f670c3c85f        k8s.gcr.io/pause:3.2   "/pause"                2 minutes ago       Up 2 minutes                                    k8s_POD_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_0 $ sudo docker logs k8s_hello_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_4 hello world!

kubelet прочитал манифест пода и дал Docker’у команду запустить пару контейнеров в соответствии с нашей спецификацией. (Если вам интересно узнать про контейнер “pause”, то это хакерство Kubernetes — подробности смотрите в этом блоге.) Kubelet запустит наш контейнер busybox с указанной командой и будет перезапускать его бесконечно, пока статический под не будет удален.

Поздравьте себя. Мы только что придумали один из самых запутанных способов вывода текста в терминал!

Запускаем etcd

Нашей конечной целью является запуск Kubernetes API, но для этого нам сначала нужно запустить etcd. Давайте запустим минимальный кластер etcd, поместив его настройки в каталог pods (например, pods/etcd.yaml):

apiVersion: v1 kind: Pod metadata:   name: etcd   namespace: kube-system spec:   containers:   - name: etcd     command:     - etcd     - --data-dir=/var/lib/etcd     image: k8s.gcr.io/etcd:3.4.3-0     volumeMounts:     - mountPath: /var/lib/etcd       name: etcd-data   hostNetwork: true   volumes:   - hostPath:       path: /var/lib/etcd       type: DirectoryOrCreate     name: etcd-data

Если вы когда-либо работали с Kubernetes, то подобные YAML-файлы должны быть вам знакомы. Здесь стоит отметить только два момента:

Мы смонтировали папку хоста /var/lib/etcd в под, чтобы данные etcd сохранялись после перезапуска (если этого не сделать, то состояние кластера будет стираться при каждом перезапуске пода, что будет нехорошо даже для минимальной установки Kubernetes).
Мы установили hostNetwork: true. Этот параметр, что неудивительно, настраивает etcd для использования сети хоста вместо внутренней сети пода (это облегчит API-серверу поиск кластера etcd).

Простая проверка показывает, что etcd действительно запущен на localhost и сохраняет данные на диск:

$ curl localhost:2379/version {"etcdserver":"3.4.3","etcdcluster":"3.4.0"} $ sudo tree /var/lib/etcd/ /var/lib/etcd/ └── member     ├── snap     │   └── db     └── wal         ├── 0.tmp         └── 0000000000000000-0000000000000000.wal

Запуск API-сервера

Запустить API-сервер Kubernetes еще проще. Единственный параметр, который надо передать, --etcd-servers, делает то, что вы ожидаете:

apiVersion: v1 kind: Pod metadata:   name: kube-apiserver   namespace: kube-system spec:   containers:   - name: kube-apiserver     command:     - kube-apiserver     - --etcd-servers=http://127.0.0.1:2379     image: k8s.gcr.io/kube-apiserver:v1.18.5   hostNetwork: true

Поместите этот YAML-файл в каталог pods, и API-сервер запустится. Проверка с помощью curl показывает, что Kubernetes API прослушивает порт 8080 с полностью открытым доступом — аутентификация не требуется!

$ curl localhost:8080/healthz ok $ curl localhost:8080/api/v1/pods {   "kind": "PodList",   "apiVersion": "v1",   "metadata": {     "selfLink": "/api/v1/pods",     "resourceVersion": "59"   },   "items": [] }

(Опять же, не запускайте это в продакшене! Я был немного удивлен, что настройка по умолчанию настолько небезопасна. Но я предполагаю, что это сделано для облегчения разработки и тестирования.)
И, приятный сюрприз, kubectl работает из коробки без каких-либо дополнительных настроек!

$ ./kubectl version Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"e6503f8d8f769ace2f338794c914a96fc335df0f", GitTreeState:"clean", BuildDate:"2020-06-26T03:47:41Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"e6503f8d8f769ace2f338794c914a96fc335df0f", GitTreeState:"clean", BuildDate:"2020-06-26T03:39:24Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"} $ ./kubectl get pod No resources found in default namespace.

Проблема

Но если копнуть немного глубже, то кажется, что что-то идет не так:

$ ./kubectl get pod -n kube-system No resources found in kube-system namespace.

Статические поды, которые мы создали, пропали! На самом деле, наш kubelet-узел вообще не обнаруживается:

$ ./kubectl get nodes No resources found in default namespace.

В чем же дело? Если вы помните, то несколько абзацев назад мы запускали kubelet с чрезвычайно простым набором параметров командной строки, поэтому kubelet не знает, как связаться с сервером API и уведомлять его о своем состоянии. Изучив документацию, мы находим соответствующий флаг:

--kubeconfig string

Путь к файлу kubeconfig, в котором указано как подключаться к серверу API. Наличие --kubeconfig включает режим API-сервера, отсутствие --kubeconfig включает автономный режим.

Все это время, сами того не зная, мы запускали kubelet в «автономном режиме». (Если бы мы были педантичны, то можно было считать автономный режим kubelet как «минимально жизнеспособный Kubernetes», но это было бы очень скучно). Чтобы заработала «настоящая» конфигурация, нам нужно передать файл kubeconfig в kubelet, чтобы он знал, как общаться с API-сервером. К счастью, это довольно просто (так как у нас нет проблем с аутентификацией или сертификатами):

apiVersion: v1 kind: Config clusters: - cluster:     server: http://127.0.0.1:8080   name: mink8s contexts: - context:     cluster: mink8s   name: mink8s current-context: mink8s

Сохраните это как kubeconfig.yaml, убейте процесс kubelet и перезапустите с необходимыми параметрами:

$ sudo ./kubelet --pod-manifest-path=pods --kubeconfig=kubeconfig.yaml

(Кстати, если вы попытаетесь обратиться к API через curl, когда kubelet не работает, то вы обнаружите, что он все еще работает! Kubelet не является «родителем» своих подов, подобно Docker’у, он больше похож на “управляющего демона”. Контейнеры, управляемые kubelet, будут работать, пока kubelet не остановит их.)

Через несколько минут kubectl должен показать нам поды и узлы, как мы и ожидаем:

$ ./kubectl get pods -A NAMESPACE     NAME                    READY   STATUS             RESTARTS   AGE default       hello-mink8s            0/1     CrashLoopBackOff   261        21h kube-system   etcd-mink8s             1/1     Running            0          21h kube-system   kube-apiserver-mink8s   1/1     Running            0          21h $ ./kubectl get nodes -owide NAME     STATUS   ROLES    AGE   VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIME mink8s   Ready    <none>   21h   v1.18.5   10.70.10.228   <none>        Ubuntu 18.04.4 LTS   4.15.0-109-generic   docker://19.3.6

Давайте на этот раз поздравим себя по-настоящему (я знаю, что уже поздравлял) — у нас получился минимальный «кластер» Kubernetes, работающий с полнофункциональным API!

Запускаем под

Теперь посмотрим на что способен API. Начнем с пода nginx:

apiVersion: v1 kind: Pod metadata:   name: nginx spec:   containers:   - image: nginx     name: nginx

Здесь мы получим довольно интересную ошибку:

$ ./kubectl apply -f nginx.yaml Error from server (Forbidden): error when creating "nginx.yaml": pods "nginx" is forbidden: error looking up service account default/default: serviceaccount "default" not found $ ./kubectl get serviceaccounts No resources found in default namespace.

Здесь мы видим насколько ужасающе неполна наша среда Kubernetes — у нас нет учетных записей для служб. Давайте попробуем еще раз, создав учетную запись службы вручную, и посмотрим, что произойдет:

$ cat <<EOS | ./kubectl apply -f - apiVersion: v1 kind: ServiceAccount metadata:   name: default   namespace: default EOS serviceaccount/default created $ ./kubectl apply -f nginx.yaml Error from server (ServerTimeout): error when creating "nginx.yaml": No API token found for service account "default", retry after the token is automatically created and added to the service account

Даже когда мы создали учетную запись службы вручную, токен аутентификации не создается. Продолжая экспериментировать с нашим минималистичным «кластером», мы обнаружим, что большинство полезных вещей, которые обычно происходят автоматически, будут отсутствовать. Сервер Kubernetes API довольно минималистичен, большая часть тяжелых автоматических настроек происходит в различных контроллерах и фоновых заданиях, которые еще не выполняются.

Мы можем обойти эту проблему, установив опцию automountServiceAccountToken для учетной записи службы (так как нам все равно не придется ее использовать):

$ cat <<EOS | ./kubectl apply -f - apiVersion: v1 kind: ServiceAccount metadata:   name: default   namespace: default automountServiceAccountToken: false EOS serviceaccount/default configured $ ./kubectl apply -f nginx.yaml pod/nginx created $ ./kubectl get pods NAME    READY   STATUS    RESTARTS   AGE nginx   0/1     Pending   0          13m

Наконец, под появился! Но на самом деле он не запустится, так как у нас нет планировщика (scheduler) — еще одного важного компонента Kubernetes. Опять же, мы видим, что API Kubernetes на удивление «глупый» — когда вы создаете под в API, он его регистрирует, но не пытается выяснить, на каком узле его запускать.

На самом деле для запуска пода планировщик не нужен. Можно вручную добавить узел в манифест в параметре nodeName:

apiVersion: v1 kind: Pod metadata:   name: nginx spec:   containers:   - image: nginx     name: nginx   nodeName: mink8s 

(Замените mink8s на название узла.) После delete и apply мы видим, что nginx запустился и слушает внутренний IP-адрес:

$ ./kubectl delete pod nginx pod "nginx" deleted $ ./kubectl apply -f nginx.yaml pod/nginx created $ ./kubectl get pods -owide NAME    READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES nginx   1/1     Running   0          30s   172.17.0.2   mink8s   <none>           <none> $ curl -s 172.17.0.2 | head -4 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title>

Чтобы убедиться, что сеть между подами работает корректно, мы можем запустить curl из другого пода:

$ cat <<EOS | ./kubectl apply -f - apiVersion: v1 kind: Pod metadata:   name: curl spec:   containers:   - image: curlimages/curl     name: curl     command: ["curl", "172.17.0.2"]   nodeName: mink8s EOS pod/curl created $ ./kubectl logs curl | head -6   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                  Dload  Upload   Total   Spent    Left  Speed <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title>

Довольно интересно покопаться в этом окружении и посмотреть, что работает, а что нет. Я обнаружил, что ConfigMap и Secret работают так, как и ожидается, а Service и Deployment нет.

Успех!

Этот пост становится большим, поэтому я собираюсь объявить о победе и заявить, что это жизнеспособная конфигурация, которую можно назвать “Kubernetes". Резюмируя: четыре бинарных файла, пять параметров командной строки и “всего лишь” 45 строк YAML (не так много по стандартам Kubernetes) и у нас работает немало вещей:

• Поды управляются с помощью обычного Kubernetes API (с несколькими хаками)
• Можно загружать публичные образы контейнеров и управлять ими
• Поды остаются живыми и автоматически перезапускаются
• Сеть между подами в рамках одного узла работает довольно хорошо
• ConfigMap, Secret и простейшее монтирование хранилищ работает как положено

Но большая часть из того, что делает Kubernetes по-настоящему полезным, все еще отсутствует, например:

• Планировщик подов
• Аутентификация / авторизация
• Несколько узлов
• Сеть сервисов
• Кластерный внутренний DNS
• Контроллеры для учетных записей служб, развертываний, интеграции с облачными провайдерами и большинство других “плюшек”, которые приносит Kubernetes

Так что же мы на самом деле получили? Kubernetes API, работающий сам по себе, на самом деле, является всего лишь платформой для автоматизации контейнеров. Он не делает много — это работа для различных контроллеров и операторов, использующих API, — но он обеспечивает консистентную среду для автоматизации.

Узнать подробнее о курсе на бесплатном вебинаре.

---

Читать еще:

• Зачем сисадминам, разработчикам и тестировщикам изучать DevOps практики?
• Thanos — масштабируемый Prometheus
• Как QA-команда GitLab использует GitLab Performance Tool
• Loki — сбор логов, используя подход Prometheus
• Один день из жизни DevOps

Профессия системного администратора всегда сопровождается стереотипным восприятием. Сисадмин – это некий универсальный айтишник в любой компании, который чинит компьютеры, поднимает Интернет, занимается оргтехникой, настраивает программы и т. д. Дошло до того, что появился День Сисадмина – последняя пятница июля, то есть – сегодня. 

Более того, у праздника сегодня юбилей – первый День Сисадмина был отпразднован в 2000 году в Чикаго американским «универсальным айтишником» по имени Тед Кекатос. Это был пикник на природе с участием сотрудников небольшой софтверной компании.

В Россию праздник пришел в 2006 году, когда под Калугой состоялся Всероссийский слёт системных администраторов, к котором далее добавился аналогичный ивент в Новосибирске. 

Профессия живет и развивается, и сегодня отличный повод взглянуть на ее эволюцию, текущее состояние и перспективы, открываемые работой сисадмином в мире «больших ИТ». 

Сисадмин: вчера и сегодня

Сегодня существует множество вариаций практического наполнения работы системным администратором. 

В небольшой компании до 100 сотрудников один и тот же человек может выполнять обязанности сисадмина, менеджера, он же будет управлять лицензиями на ПО и отвечать за обслуживание оргтехники, настраивать Wi-Fi, отвечать на запросы пользователей, отвечать за серверы. Если вдруг в компании есть 1С, то соответственно, этот человек еще каким-то образом будет разбираться и в этом направлении. Такова работа сисадмина в относительно малом бизнесе.

Что касательно компаний покрупнее – сервис-провайдеров, cloud-провайдеров, разработчиков ПО и т. д., то здесь, безусловно, есть более углубленные сценарии эволюции профессии сисадмина. 

К примеру, в таких компаниях наверняка будет позиция выделенного Unix-администратора, Windows admin, обязательно будет «безопасник», а также сетевые инженеры. Наверняка у них у всех есть руководитель ИТ-отдела или ИТ-менеджер, который отвечает за управление инфраструктурой и ИТ-проекты в департаменте. В крупных компаниях понадобится уже ИТ-директор, разбирающийся в стратегическом планировании, и тут не лишним будет дополнительно получить степень MBA к уже имеющемуся техническому бэкграунду. Нет единственно правильного решения, все зависит от компании. 

Большинство молодых коллег, кто еще только начинает карьеру сисадмина, начинают с первой и второй линий техподдержки – отвечают на дурацкие вопросы пользователей, набираются опыта и приобретают навыки стрессоустойчивости. Их обучают более опытные системные администраторы, разрабатывают им алгоритмы действий по распространенным сценариям траблшутинга, настройки и т. д. Человек потихоньку обучается, и, если он успешен и ему все нравится, он постепенно дорастает до следующей ступени.

Здесь мы переходим к вопросу о том, можно ли рассматривать сисадминство, как некий портал в более серьезную ИТ-карьеру, или это какой-то замкнутый уровень, где можно развиваться лишь горизонтально? 

The sky is the limit

Прежде всего отмечу, что для сисадмина в современном мире с учетом всех ключевых направлений развития ИТ существует принципиальная возможность развиваться и расти профессионально в любом избранном направлении. 

Вначале ты специалист отдела ИТ-поддержки, потом – системный администратор, а далее встает выбор специализации. Можно пойти в программисты, в Unix-администраторы, в сетевые инженеры, а также стать системным ИТ-архитектором или специалистом по безопасности или даже менеджером проектов.

Безусловно, все не так просто – во-первых, надо набираться опыта, сдавать экзамены по различным учебным программам, получать сертификаты, регулярно доказывать, что ты способен показывать результат и применять полученные знания и опыт, постоянно обучаться. Если сисадмин выбирает путь развития в направлении системного архитектора, то здесь можно рассчитывать на зарплату не хуже, чем у ИТ-руководителей. 

Кстати, из сисадмина можно пойти и в ИТ-менеджмент. Если тебе нравится управлять, сотрудничать, направлять – то тебе путь заказан в область управления проектами. 

Как вариант – можно остаться системным администратором на очень хорошем профессиональном уровне, и развиваться в узкоспециализированной области, например в какой-нибудь облачном провайдере, сосредотачиваясь на задачах по облачной инфраструктуре и виртуализации.

К счастью для сисадминов, сегодня нет такой возможности, которая не была бы открыта для коллег – каждый выбирает сам, куда ему дальше расти и развиваться. 

Образование переоценено?

Хорошая новость: можно говорить, что порог вхождения в ИТ через позицию сисадмина не требует специального, скажем, математического, образования. 

Среди знакомых встречалось немало гуманитариев, которым удалось построить успешную карьеру, начав с ИТ-саппорта и далее по описанному маршруту. Сисадминство здесь становится отличными «ИТ-университетами». 

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

В целом, если человек захотел стать сисадмином, то сегодня это не такая закрытая профессия, как, скажем, пилот истребителя. Начать движение в сторону своей мечты можно буквально на диване дома с изучения литературы или курсов с экрана смартфона. Очень много информации по любому направлению доступно в виде бесплатных и платных курсов и статей.

Есть возможность подготовиться к своей первой ИТ-работе дома и совершенно спокойно потом устроиться в ИТ-поддержку. 

Безусловно, те, кто обучался смежным специальностям в вузе, имеет стартовое преимущество, но, с другой стороны, человек с хорошим математическим образованием вряд ли планирует пойти в поддержку или в сисадмины, скорее всего он выберет другой путь – например Big Data.  А это серьезно снижает конкуренцию непосредственно на начальном уровне вхождения в отрасль. 

Навыки: топ-5 сисадминских «скиллов»-2020

Конечно, определенный набор навыков для успешной работы сисадмином в условиях 2020 года все же необходим. Вот он. 

Прежде всего – это желание работать и расти в этой профессии, энтузиазм, работоспособность и готовность постоянно учиться. Это главное. 

Если человек где-то услышал, что сисадмин – это круто, но, попробовав, понял, что ему профессия не нравится, то лучше не тратить время зря и сменить специальность. Профессия требует к себе отношения «всерьез и надолго». В ИТ постоянно что-то меняется. Здесь нельзя разово что-то выучить и сидеть на этих знаниях лет 10 и ничего не делать, не изучать что-то новое. «Учиться, учиться и еще раза учиться.» /В. И. Ленин/

Второй важный аспект скиллсета – это хорошая память и аналитические навыки. Постоянно нужно держать в голове массу знаний, добавлять к ней новые объемы и предметные области, уметь творчески их осмысливать и преобразовывать в сумму полезных профессиональных действий. И уметь выуживать и применять знания и опыт в нужный момент.

Третья часть – минимальный набор профессиональных знаний. Для выпускников профильных технических вузов будет достаточно: знания основы баз данных, принципов устройства ОС (не глубоко, не на уровне архитектора), представления о том, как софт взаимодействует с «железом», понимания принципов работы сетей, а также начальных навыков в программировании, базовых знаний TCP/IP, Unix, Windows систем. Умеешь переустанавливать Window и собрать свой компьютер самостоятельно – значит уже почти готов стать сисадмином. 

Одна из примет времени сегодня – автоматизация, каждый сисадмин приходит к тому, что какие-то процессы проще прописать на уровне скриптов, сокращая таким образом свой нудный ручной труд. 

Четвертый пункт — знание английского языка, это совершенно обязательный навык. Пополнять свой личный багаж знаний лучше из первоисточников, язык ИТ сегодня – это English. 

Наконец, пятый аспект скиллсета сисадмина образца 2020 года – мультифункциональность. Сейчас все переплетено, к примеру, и Windows и Unix, как правило, перемешаны в одной инфраструктуре по разным блокам задач. 

Unix используется сейчас практически везде, и в корпоративных ИТ-инфраструктурах, и в облаках, на Unix уже работает 1C и MS SQL, а также облачные сервера Microsoft и Amazon cloud. 

В зависимости от специфики работы в конкретной компании от сисадмина может потребоваться умение быстро разобраться в самых неожиданных вещах, быстро встроить в процессы компании какое-нибудь готовое облачное приложение или его API.  

Словом, нужно соответствовать стереотипу #тыжайтишник и уметь работать на результат по любым задачам.  

DevOps почти не виден

Один самых очевидных сценариев и трендов развития карьеры сисадмина сегодня – DevOps; таков, по крайней мере, стереотип. 

На самом деле, все не так просто: DevOps специалист в современном ИТ – это больше помощник программиста, который постоянно доводит до ума и «чинит» инфраструктуру, разбирается, почему код заработал на одной версии библиотеки, а на другой не заработал. DevOps также автоматизирует разные алгоритмы по развертыванию и тестированию продукта на своих или облачных серверах, помогает выбрать и сконфигурировать архитектуру ИТ-компонентов. И безусловно он может что-то «напрограммировать» и прочитать чужой код, но это не его основная функция.

DevOps – это, по сути, немножко более специализированный системный администратор. Так его назвали, но профессию и задачи по сути это не изменило. Опять же сейчас эта профессия в тренде, но кто не успел туда зайти, имеют шанс сделать это на протяжении около 5 следующих лет. 

Сегодня восходящий тренд в области построения ИТ-карьеры от уровня сисадмина – робототехника и автоматизация (RPA), ИИ и Big Data, DevOps, Cloud admin.

Профессия сисадмина всегда находится на стыке разных предметных областей, это некий конструктор компетенций и навыков для самостоятельной сборки.  Не лишним будет получить скилл – стрессоустойчивости и минимальные знания психологии. Не стоит забывать, что вы работаете не только с ИТ, но и с людьми, которые бывают очень и очень разными. Вам также придется не раз объяснять, почему ваше ИТ-решение лучше, чем другие, и почему стоит использовать именно его.

Добавлю, что профессия будет оставаться востребованной неограниченно долго. Потому что все обещания крупных ИТ-вендоров, анонсирующих выпуск «полностью самодостаточных платформ и систем, которые не будут ломаться, будут сами себя обслуживать и чинить», пока что не подтверждаются практикой. Об этом то и дело говорят Oracle, Microsoft и другие крупные компании. Но ничего такого не происходит, потому что информационные системы остаются предельно разнообразными и неоднородными с точки зрения платформ, языков, протоколов и т.д. Никакой искусственный интеллект пока не в состоянии настроить гладкую работу комплексных ИТ-архитектур безошибочно и без вмешательства человека. 

А это значит, что сисадмины будут нужны еще очень долго и с очень высокими требованиями к их профессионализму. 

IT-manager компании Linxdatacenter Илья Ильичев

Когда-то давно я понял, что мне мотора Иж Планета не хватает и я решил радикально модифицировать его — сделать собственный цилиндр. По ходу сменился даже мотор. За его время я успел закончить школу, поступить в один вуз, вылететь и каким-то чудом перевестись в другой и отучиться там еще 5 лет и все равно я закончил и его уже два года назад. Знал бы я, что так оно растянется, наверное, не ввязался бы. Поскольку мы воспринимаем время относительно прожитого в сознательном возрасте, то для меня оно растянулось на половину прожитого времени.

Прошло уже 6 лет с момента выхода первой и последней заметки по этому проекту(Свой 2-тактный мотор. CR620 рекомендуется к ознакомлению). Тогда я остановился из-за проблем с аутсорсом в металлообработке. Кто не может, кто не хочет, кто делает бесконечно долго, кто и детали назад возвращать не хочет. А город в котором я живу имеет славную промышленную историю и был центром Петровской индустрии 18-века, но от славного прошлого ныне остался один корень в названии города и несколько действующих предприятий, на которых занято порядка единиц процентов населения. А сейчас не 90-е и даже не 00-е, когда можно было договорится с человеком с завода чтобы он что-то такое эдакое для тебя сделал. Теперь у них есть работа и КПП на входе, как я потом узнал — номинальное. Вся эта история с передачей деталей где они лежат, а не делаются, поиск новых мест и тому подобное блуждание длилась несколько лет. Оказалось, что отлить сложную алюминиевую отливку у сарая на родительской даче я смог, а обработать, что не выглядело проблемой изначально — нет.

В это же время я познакомился с мастером из университетской мастерской, который сначала под присмотром, а потом и самостоятельно позволял мне работать на станках. Жаль только то, что станки были чуть больше настольного и моя отливка не имела шанса влезть в них. Однако, я делал на них маленькие детали на продажу и заработал на токарный станок уже промышленного уровня, пусть и выпущенный на заводе сомнительной репутации в АрССР.

Из помещений, где я мог что-то делать, был кусок в 3х3м сарая на родительской даче и гараж-ракушка. В одном нет места в другом света. Я решил, что с электричеством проблема проще и перевез станок в гараж. Там я его отмыл, перебрал и изучил. Казалось бы, электричество есть в кооперативе напротив через кусты и грунтовку, в 10м. Связался с председателем и предложил ему платить все взносы за право покупать у его кооператива электричество. От категорически был против. Фейл. Соседей пенсионеров мне тоже убедить не удалось. Фейл. Появилась идея снять с товарищами гараж для хранения и ремонта мототехники. Звонили по объявлениям, ездили смотреть и каждый раз общение с собственником помещения заканчивалось после вопроса о установке станка. Фейл. Проект как обычно отложен на следующий год.

К концу лета следующего года я, видимо, настолько утомил родителей терриконами отходов литейного производства на даче (на мой взгляд хорошо разбавляли сельский пейзаж и избавляли от стрижки травы в пределах пары метров от них), что они решили купить мне гараж у дома и с электричеством, аж с тремя фазами по стенке. Там наконец токарный станок ожил, а я смог начать обрабатывать отливку цилиндра после 2,5 лет выдержки.

Когда я наконец обработал отливку, то столкнулся с очередной проблемой: я договорился с человеком, который делает сверхтвердые гальванические покрытия на цилиндрах ДВС и проектировал цилиндр именно под покрытие, а пока время шло, человек уже перестал этим заниматься или просто не стал браться, а другие либо делали дорого, либо как-то очень подозрительно путались в ответах. К тому же, колодцы золотников были выполнены вертикальными, при проектировании я не мог думать как технолог, ибо не имел свой производственной базы. Такие я не мог обработать сам и отдал на сторону, где цилиндр повис на полгода. Так проект встал, хотел закончить к лету, никогда такого не было и вот опять. Нужно было делать чугунную гильзу, да только к тому времени накопилось столько новых идей, что проект 4-годичной давности устарел и тащить его не было никакого желания. Так эта ветвь и остановилась навечно.

Зимой был подготовлена новая версия цилиндра. Именно с этого момента можно отсчитывать хронологию проекта. Отличительной особенностью ее является обилие «механизации» — два клапана в каналах выпуска и золотники в каналах продувки.
Начнем, пожалуй, с небольшой теории о мощностных клапанах в двухтактных двигателях внутреннего сгорания.

Введение

К настоящему времени в двухтактных двигателях с кривошипно-камерной продувкой применяются системы управления сечением и/или фазой выпускного порта. Данные системы обеспечивают сглаживание кривой мощности. Изменение фазы или сечения выпускного порта выполняется с помощью заслонки, расположенной в выпускном канале. Ее положение зависит от оборотов коленчатого вала. Привод заслонки бывает пневматическим, механическим или электрическим. Например, на моторе мотоцикла Yamaha TZ500 при высоких оборотах, около 10500 мин-1, значение фазы выпуска составляет 202deg, а на низких около 180deg. На рисунке представлена конструкция мощностного клапана фирмы Yamaha.

Как и для выпуска, для продувки тоже существует зависимость оптимальной фазы продувки от оборотов, обусловленная компромиссом между скоростью газа в потоке продувки, потерями свежей смеси через выпуск и объемом ее же, поступающей за время продувки. Данная зависимость линейна, что можно увидеть из графика, представленного ниже.

В отличие от выпускного порта, каналы продувки характеризуются еще и углами выхода: горизонтальными и вертикальными. В случае пятиканальной продувки обычно получается четыре ненулевых и различных горизонтальных угла и пять (по два на 1-4 каналы и один на 5-й) вертикальных.

Горизонтальные углы продувочных каналов: A, B, C, D

Вертикальные углы основных каналов продувки

Данные углы необходимы для получения характерной петли продувки. Такой способ продувки называется петлевая продувка и обеспечивает наиболее эффективное удаление отработанных газов без увеличения числа подвижных элементов двигателя и усложнения его конструкции. Поэтому в настоящее время только он применяется на всех двухтактных двигателях, кроме двухтактных дизелей. Из-за важности углов выхода продувочных каналов применять методы, используемые для управления выпуском, нельзя. Поскольку они будут создавать либо нежелательные завихрения в канале продувки, либо изменять его углы выхода.

Авторы [A. Graham Bell. Two-Stroke Performance Tuning. Haynes Publishing, 1999.] утверждают, что во время продувки возникают колебания с собственной частотой $$:

$$

где:
$$ — скорость звука в продувочном канале;
$$ — объем кривошипной камеры без учета объема продувочных каналов;
$$ — средняя длина продувочного канала;
$$ — средняя площадь поперечного сечения продувочного канала;
$$ — ширина среднего поперечного сечения канала;
$$ — высота среднего поперечного сечения канала.
Выражение $$ представляет собой поправку, учитывающую влияние входной части продувочного канала.
Эта собственная частота, $$, должна быть равна:

$$

где:
$$ — чистота оборотов коленчатого вала двигателя;
$$ — фаза продувки.
Таким образом, из выражения (2) следует, что собственная частота колебаний, возникающих во время продувки, прямо пропорциональна частоте оборотов двигателя, но правая часть выражения (1) не зависит от частоты вращения коленчатого вала. Поэтому продувка оптимально работает лишь в узком диапазоне оборотов, а для расширения рабочего диапазона необходимо внести зависимость от оборотов в правую часть выражения (1). Проще всего это сделать, введя зависимость средней площади поперечного сечения продувочного канала от оборотов. Чтобы не вносить нежелательных завихрений в поток газа в продувочном канале, желательно изменять сечение каналов продувки, меняя их количество. Например, с помощью золотников, перекрывающих некоторые каналы продувки. В рамках данного проекта предлагается перекрывать золотниками дополнительные каналы продувки.

Золотники в каналах продувки: левый полностью открыт, правый закрыт

Влияние данного решения было исследовано с помощью компьютерного моделирования продувки в пакете программ SolidWorks Flow Simulation. Продувка выполнена при постоянной разнице давлений между входом в каналы продувки и выходом из выпускного канала. Поршень считался неподвижным и находящимся в нижней мертвой точке. Процессы впуска и выпуска не учитывались. Разница давлений была выбрана из разницы объемов под поршнем в нижней и верхней мертвой точке и составляла 0,6 кг/см2. Из-за указанных выше допущений, результаты расчета в этом стационарном приближения можно рассматривать как качественные без количественной оценки. Поскольку, например, разделить во времени или пространстве процессы выпуска и продувки нельзя. В этом и заключается главная трудность для компьютерного моделирования двухтактных двигателей с кривошипно-камерной продувкой.

На рисунках видно, что закрытие золотников существенно влияет на распределение скоростей потока и вид петли продувки: при закрытых дополнительных каналах (трехканальный режим) увеличивается скорость газа в процессе продувки и петля продувки становится более выраженной и отдаленной от выпускного окна, что должно снизить потери свежей смеси через выпускной порт и снизить коэффициент остаточных газов, в тоже время, высокая скорость на выходе потока из каналов продувки при трехканальной продувке указывает на наличие узкого места, которое будет ограничивать расход газа через двигатель, а значит и мощность при высоких оборотах. В случае пятиканального режима смешивание газов должно быть больше, а, значит, возрастет коэффициент остаточных газов, но при этом наблюдается меньшая скорость, и «узким» местом становится канал выпуска, что снижает потери свежей смеси через него.

Траектории 2000 частиц при открытых золотниках в дополнительных продувочных каналах (пятиканальный режим)

Траектории 2000 частиц при закрытых золотниках в дополнительных продувочных каналах (трехканальный режим)

Кроме золотников в каналах продувки, планируется установить в выпускном канале мощностной клапан (МК) для проверки совместной работы обоих систем. Наилучшим образом для исполнительного механизма МК подходит заслонка в виде секторного золотника. Это объясняется тем, что кромка заслонки такого мощностного клапана во всем диапазоне рабочего хода находится максимально близко к рабочей поверхности цилиндра (то есть, при малом угле поворота траектория движения точке на кромке золотника приближена к прямой), а не только в нижнем положение, как в случае цилиндрического золотника или наклонного шибера. Кроме того, такая конструкция заслонки не создает сильных завихрений за собой как шиберная заслонка, движущаяся параллельно оси цилиндра.

Заслонка мощностного клапана(МК) в опущенном состоянии

Продувки при закрытых золотниках в дополнительных каналах продувки и опущенной заслонке МК

Разработка моделей

На основании информации (таблица), полученной входе изучения цилиндров мотоциклов Kawasaki KX500, Honda CR500, Yamaha YZ490 и CZ 514, были выбраны фазы продувки и выпуска соответственно равные 125deg и 186deg, с полностью закрытым мощностным клапаном фаза выпуска уменьшается до 156о. Число продувочных каналов выбрано равным пяти и выпуск из двух основных окон и двух дополнительных портов. На впуске был установлен лепестковый клапан.

Примечание: Если в ячейке указаны два параметра высоты выпускного окна или фазы выпуска, то первая относится к состоянию с полностью закрытым МК, а вторая с открытым.

После замеров сопрягаемых с цилиндром элементов базового двигателя было выполнено создание трехмерной твердотельной модели газораспределительных каналов и сопряженных с ними полостей. Все чертежи были выполнены с использованием пакета программ SolidWorks.

Твердотельная модель газораспределительных каналов

Начало именно с твердотельной модели каналов позволяет минимизировать число толстых мест отливки и уменьшить ее массу. На следующем шаге вокруг модели каналов была построена оболочка с толщиной стенок 4-6 мм и нижним крепежным фланцем.

Оболочка каналов без выреза модели каналов

Рубашка охлаждения была получена построением вокруг оболочки каналов второй оболочки, такой чтобы между обоими оболочками в горячих местах (верхняя часть цилиндра и каналы выпуска) оставалось расстояние в 6-10 мм. Толщина стенки оболочки каналов охлаждения около 4 мм. Вход в рубашку охлаждения находится внизу цилиндра под каналом выпуска и выше верхней кромки продувочных каналов рубашка охватывает весь периметр цилиндра. Также на этом этапе были построены плоскости крышек системы газораспределения и фланцы впуска и выпуска.

Твердотельная модель цилиндра без выреза модели каналов

Модель цилиндра получена при вычитании из полученной на предыдущем этапе модели каналов, таким образом модель каналов формирует полости. Далее была выполнена разметка крепежных отверстий, посадок подшипников и гильзы. На этом построение модели цилиндра закончено.

Построение гильзы и золотников было выполнено так же с помощью вычитания модели каналов из соответствующих твердотельных «заготовок».

Получилось и так много текста, поэтому за сим завершаю эту часть. Следующая будет повествовать о изготовлении литейной оснастки и выполнении отливки цилиндра.

Приветствую. Представляю вашему вниманию перевод статьи «CSS News July 2020», опубликованной 7 июля 2020 года автором Rachel Andrew

В последнее время скорость внедрения новых возможностей технологий веб-разработки существенно увеличилась по сравнению с тем, как это было раньше. Данная статья содержит подборку новых CSS-функций, поддержка которых уже сейчас появляется в современных браузерах. Если вы относитесь к разработчикам, которым не нравится читать о технологиях, если их нельзя сразу же начать применять, вероятно, эта статья может быть вам не интересна. Однако, если вам интересно узнать, что нас ждёт в самое ближайшее время и уже сейчас опробовать это в бета-версии браузера, тогда читайте дальше.

Gap для Flexbox

Давайте начнём с того, что уже реализовано в релизной версии одного браузера и бета-версиях других браузеров.

На момент перевода статьи поддерживается всеми современными браузерами (насчёт Safari точно неизвестно)

В CSS Grid мы можем использовать свойства gap, column-gap и row-gap для определения отступов между рядами, колонками или и тем и другим одновременно. Свойство column-gap также встречается в Мультиколонках для создания отступов между этими самыми колонками.

Хотя для создания отступов между grid-элементами можно использовать margin, плюсом свойства gap является то, что вы получаете отступы только между элементами, отступы от края grid-контейнера при этом не образуются. До сих пор для создания отступов между flex-элементами мы, как раз, и использовали margin. При этом, чтобы не допустить появления отступов от края flex-контейнера, приходилось применять к нему отрицательные margin.

Было бы неплохо иметь такое же свойство gap и для Flexbox, не так ли? Хорошая новость в том, что это произошло – его поддержка уже реализована в Firefox и Chrome.

В следующем CodePen вы можете увидеть все три варианта. В первом варианте flex-элементы используют margin с каждой стороны. Это создаёт отступ в начале и в конце flex-контейнера. Во втором варианте для flex-контейнера используется отрицательный margin, чтобы вытащить этот выступающий margin за пределы границ контейнера. В третьем примере margin не используются, а вместо них задаётся gap: 20px, создающий отступ только между элементами.

Mind the Gap

Реализация gap для Flexbox выделяет несколько интересных моментов. Во-первых, как вы можете помнить, когда функционал отступов был впервые представлен в Grid Layout, были свойства:

• grid-gap
• grid-row-gap
• grid-column-gap

Эти свойства были доступны сразу, как только браузеры получили поддержку CSS Grid. Но как свойства выравнивания (justify-content, align-content, align-items) сначала появились в Flexbox, а потом стали доступны в Grid, так и свойства gap со временем были переименованы и стали доступны не только в CSS Grid.

Вместе со свойствами выравнивания, свойства gap теперь относятся к спецификации "Box Alignment". Данная спецификация работает с выравниванием и распределением пространства, поэтому является лучшим местом для них. Чтобы уберечь нас от получения множества свойств, с префиксами из каждой спецификации, они также были переименованы, чтобы избавиться от префикса "grid–".

Если же в вашем коде встречаются свойства с префиксом grid–, не стоит беспокоиться. Такой способ записи был оставлен как псевдоним для этих свойств, поэтому ваш код не сломается.

Проверка поддержки свойств "gap" для Flexbox

Вы могли подумать, что можете свободно применять свойства "gap" для Flexbox, а для проверки наличия его поддержки использовать функциональные запросы "Feature Queries" с фолбэком с использованием "margin". К сожалению, это не так, поскольку функциональные запросы проверяют имя и значение. Например, если я хочу проверить наличие поддержки CSS Grid, я могу использовать следующий запрос:

@supports (display: grid) {   .grid {     /* grid layout code here */   } }

При проверке же поддержки свойства gap: 20px, я бы получила положительный ответ от Chrome, который на момент составления статьи не поддерживал "gap" в Flexbox, но поддерживал в CSS Grid. Всё, что делают функциональные запросы, так это проверяют, распознаёт ли браузер свойство и значение. У них нет возможности проверить наличие поддержки данного свойства в режиме раскладки Flexbox. Я подняла этот вопрос как проблему в рабочей группе CSS, однако это оказалось не так просто исправить.

Соотношение сторон

Порой нам хочется, чтобы даже при адаптивном изменении размеров, элемент сохранял фиксированное соотношение сторон. Например, в случае с изображениями или видео. Если вы размещаете на странице изображения или видео непосредственно с помощью HTML-тегов img или video, они по умолчанию сохраняют изначально присущее им соотношение сторон (если только вы принудительно не измените ширину или высоту). Однако, порой нам нужно добавить элемент, у которого одна сторона гибко заполняет доступное пространство, а другая – изменяется исходя из заданного соотношения сторон. Чаще всего это применяется при встраивании в разметку видео через фрейм, однако помимо этого, вы можете захотеть сделать, например, идеальные квадратные области на сетке (или что-то другое, что требует, чтобы размер одной стороны изменялся в зависимости от изменения размера другой).

В данный момент для задания подобного поведения мы используем приём с padding, который основывается на том, что при использовании процентов, размер верхнего и нижнего "padding" элемента рассчитывается исходя из его ширины. Это не самое элегантное решение проблемы, но оно работает.

Новое свойство "aspect-ratio" решает эту задачу, позволяя нам указать необходимое соотношение сторон элемента. Chrome реализовал это в версии "Canary", поэтому вы можете увидеть пример работы данного функционала, если активируете флаг "Experimental Web Platform Features".

Я создала grid-раскладку и задала элементам сетки соотношение сторон "1 / 1". Ширина элементов определяется шириной их колоночного трека. Высота рассчитывается из ширины, чтобы образовать квадрат. Затем я добавила небольшой поворот.

В Chrome Canary можно ознакомиться с демо, чтобы увидеть, как даже при увеличении или сужении трека, элементы остаются квадратными благодаря тому, что их высота рассчитывается в пропорции "1 / 1" по отношению к ширине.

Встроенная поддержка Masonry

Разработчики часто спрашивают, может ли CSS Grid использоваться для создания Masonry или Pinterest-подобного макета. Хотя некоторые демо с разметкой, созданной с помощью CSS Grid, и похожи на подобные решения, данная технология разрабатывалась не для создания Masonry сеток.

Чтобы объяснить это, вам нужно иметь представление, что такое Masonry. В типичной Masonry сетке элементы отображаются построчно. Как только первая строка заполнена, элементы начинают заполнять следующую. Однако, если некоторые из элементов, расположенных в первой строке, короче других, элементы из второй строки расположатся выше, чтобы заполнить пробел. При помощи JavaScript такая сетка реализовывается при помощь библиотеки Masonry.

Если вы попытаетесь создать такой макет с помощью CSS Grid и его свойств автоматического расположения элементов, то увидите, что упомянутое смещение элементов вверх для заполнения пробелов отсутствует. Они располагаются в конкретных строках и колонках, потому что именно для такого поведения Grid и разрабатывался.

Так может ли CSS Grid использоваться для создания Masonry сетки? Один из инженеров Mozilla считает, что может и создал прототип такого функционала. Вы можете попробовать его с помощью Firefox Nightly, в разделе по URL-адресу about:config установив флаг layout.css.grid-template-masonry-value.enabled, на значение true.

Хотя это может быть очень востребованным для всех, кто создавал такой тип разметки с помощью JavaScript, многие из нас задаются вопросом, является спецификация CSS Grid подходящим местом для определения этого очень специфичного функционала. Вы можете ознакомиться с моими размышлениями по этому поводу в статье "Does Masonry Belong In The CSS Grid Specification?".

Subgrid

Мы уже слышали раньше о начале поддержки значения subgrid в свойствах grid-template-columns и grid-template-rows в браузере Firefox. Использование этого значение подразумевает, что дочерние сетки могут наследовать размер и количество треков от сетки родительской. То есть, если элемент имеет свойство display: grid он может наследовать структуру строк и столбцов, которые он занимает на родительской сетке.

С данным функционалом можно ознакомиться в браузере Firefox. Также, у меня есть множество примеров, которые можно попробовать реализовать. Статья "Digging Into The Display Property: Grids All The Way Down" объясняет, чем Subgrid отличается от вложенных Grid-сеток, а "CSS Grid Level 2: Here Comes Subgrid" является введением в спецификацию. Также, у меня есть несколько примеров в “Grid by Example”.

Тем не менее, первый вопрос, который люди задают, когда говорю о Subgrid – "Когда он станет доступен в Chrome?". Я всё ещё не могу сказать, когда именно, но некоторые первые новости уже видны в самом ближайшем будущем. 18 июня в блоке Chromium я анонсировала, что команда Microsoft Edge (в данный момент работающая над Chromium) перерабатывает Grid Layout в движок LayoutNG (движок следующего поколения для браузера Chromium). Часть этой работы также будет включать внедрение поддержки Subgrid.

Добавление функционала в браузер – процесс не быстрый, однако именно команда Microsoft первой реализовала поддержку CSS Grid в виде ранней реализации в IE10. Так что это отличные новости и с нетерпением жду возможности протестировать бета-версию.

prefers-reduced-data

Пока что не реализовано ни в одном браузере – но есть в списке задач на реализацию в Chrome. Это позволит CSS проверять, активировал ли посетитель сайта режим экономии трафика на своём устройстве, и соответствующим образом настраивать выдаваемое содержимое. Например, вы можете не подгружать изображения на странице, заменив их заглушками.

@media (prefers-reduced-data: reduce) {   .image {     background-image: url("images/placeholder.jpg");   } }

Медиа-запрос "prefers_reduced_data" работает так же, как некоторые уже реализованные в 5 уровне Спецификации медиа-запросов свойства, определяющие предпочтения пользователя. Например, медиа-запросы "prefers_reduced_motion" и "prefers_color_scheme" позволяют вам узнать, предпочитает ли пользователь уменьшить количество анимаций на сайте или может использует тёмную тему во всей операционной системе и соответствующим образом настроить CSS.

::marker

Псевдоэлемент "::marker" позволяет нам работать с маркером конкретного элемента списка. В самом простом случае это значит, что мы можем поменять его цвет или размер. Раньше это было невозможно из-за того, что можно было работать только со всем списком целиком.

В дополнение к стилизации маркеров настоящих списков, "::marker" можно использовать и для других элементов, списками не являющимися. В примере ниже у меня есть заголовок, которому присвоено свойство "display: list-item" и следовательно имеет маркер, который я заменила на emoji.

"::marker" уже браузером Firefox и в Chrome Canary.

Примечание: прочитать больше про псевдоэлемент "::marker" и другие связанные со списками функции можно в моей статье CSS Lists, Markers, And Counters

Пожалуйста, тестируйте новые функции

Я рекомендую пробовать применять новый функционал, если вам встречаются подходящие ситуации. Вы можете найти ошибку или что-то, что работает не так, как вы ожидали. Разработчики браузеров и Рабочая группа CSS с удовольствием хотели бы узнать о них. Если кажется, что вы нашли ошибку в работе браузера, например, заметили, что "::marker" в Chrome и Firefox ведёт себя по-разному, зафиксируйте эту проблему (в статье How to file a good browser bug описывается, как лучше это сделать). Если вы считаете, что в спецификации следовало бы предусмотреть обработку ещё какого-то поведение, также зафиксируйте это как проблему в GitHub-репозитории рабочей группы CSS