Часто доступ к веб ресурсам осуществляется не напрямую, а через обратные прокси. Причём чаще доступ именно такой, а не прямой. При возможности, я всегда ставлю обратные прокси перед сайтами даже в небольших проектах. Это и удобнее, и безопаснее, но немного более хлопотно в управлении.
Для проксирования запросов в Docker контейнеры очень удобно использовать Traefik. Удобство это в первую очередь проявляется в тестовых задачах, где часто меняется конфигурация контейнеров с приложениями, их домены, а также возникают задачи по запуску нескольких копий типовых проектов. Для прода это не так актуально, потому что он обычно более статичен в этом плане.
Сразу покажу на практике, в чём заключается удобство Traefik и в каких случаях имеет смысл им воспользоваться. Для примера запущу через Traefik 2 проекта test1 и test2, состоящих из nginx и apache и тестовой страницы, где будет указано имя проекта. В этом примере будет наглядно виден принцип работы Traefik.
Запускаем Traefik через
Можно сходить в веб интерфейс по ip адресу сервера на порт 8080. Пока там пусто, так как нет проектов. Создаём первый тестовый проект. Готовим для него файлы:
Запускаем этот проект:
В веб интерфейсе Traefik, в разделе HTTP появится запись:
Теперь можно скопировать проект test1, изменить в нём имя домена и имя внутренней сети на test2 и запустить. Traefik автоматом подцепит этот проект и будет проксировать запросы к test2.server.local в nginx-test2. Работу этой схемы легко проверить, зайдя откуда-то извне браузером на test1.server.local и test2.server.local. Вы получите соответствующую страницу index.html от запрошенного проекта.
К Traefik легко добавить автоматическое получение TLS сертификатов от Let's Encrypt. Примеров в сети и документации много, настроить не составляет проблемы. Не стал показывать этот пример, так как не уместил бы его в формат заметки. Мне важно было показать суть - запустив один раз Traefik, можно его больше не трогать. По меткам в контейнерах он будет автоматом настраивать проксирование. В некоторых ситуациях это очень удобно.
#webserver #traefik #devops
Для проксирования запросов в Docker контейнеры очень удобно использовать Traefik. Удобство это в первую очередь проявляется в тестовых задачах, где часто меняется конфигурация контейнеров с приложениями, их домены, а также возникают задачи по запуску нескольких копий типовых проектов. Для прода это не так актуально, потому что он обычно более статичен в этом плане.
Сразу покажу на практике, в чём заключается удобство Traefik и в каких случаях имеет смысл им воспользоваться. Для примера запущу через Traefik 2 проекта test1 и test2, состоящих из nginx и apache и тестовой страницы, где будет указано имя проекта. В этом примере будет наглядно виден принцип работы Traefik.
Запускаем Traefik через
docker-compose.yaml:# mkdir traefik && cd traefik
# mcedit docker-compose.yaml
services:
reverse-proxy:
image: traefik:v3.0
command: --api.insecure=true --providers.docker
ports:
- "80:80"
- "8080:8080"
networks:
- traefik_default
volumes:
- /var/run/docker.sock:/var/run/docker.sock
networks:
traefik_default:
external: true
# docker compose up
Можно сходить в веб интерфейс по ip адресу сервера на порт 8080. Пока там пусто, так как нет проектов. Создаём первый тестовый проект. Готовим для него файлы:
# mkdir test1 && cd test1
# mcedit docker-compose.yaml
services:
nginx:
image: nginx:latest
volumes:
- ./app/index.html:/app/index.html
- ./default.conf:/etc/nginx/conf.d/default.conf
labels:
- "traefik.enable=true"
- "traefik.http.routers.nginx-test1.rule=Host(`test1.server.local`)"
- "traefik.http.services.nginx-test1.loadbalancer.server.port=8080"
- "traefik.docker.network=traefik_default"
networks:
- traefik_default
- test1
httpd:
image: httpd:latest
volumes:
- ./app/index.html:/usr/local/apache2/htdocs/index.html
networks:
- test1
networks:
traefik_default:
external: true
test1:
internal: true
# mcedit default.conf
server {
listen 8080;
server_name _;
root /app;
index index.php index.html;
location / {
proxy_pass http://httpd:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}# mcedit app/index.html
It's Container for project test1
Запускаем этот проект:
# docker compose up
В веб интерфейсе Traefik, в разделе HTTP появится запись:
Host(`test1.server.local`) http nginx-test1@docker nginx-test1Он по меткам в docker-compose проекта test1 автоматом подхватил настройки и включил проксирование всех запросов к домену test1.server.local в контейнер nginx-test1. При этом сам проект test1 внутри себя взаимодействует по своей внутренней сети test1, а с Traefik по сети traefik_default, которая является внешней для приёма запросов извне.
Теперь можно скопировать проект test1, изменить в нём имя домена и имя внутренней сети на test2 и запустить. Traefik автоматом подцепит этот проект и будет проксировать запросы к test2.server.local в nginx-test2. Работу этой схемы легко проверить, зайдя откуда-то извне браузером на test1.server.local и test2.server.local. Вы получите соответствующую страницу index.html от запрошенного проекта.
К Traefik легко добавить автоматическое получение TLS сертификатов от Let's Encrypt. Примеров в сети и документации много, настроить не составляет проблемы. Не стал показывать этот пример, так как не уместил бы его в формат заметки. Мне важно было показать суть - запустив один раз Traefik, можно его больше не трогать. По меткам в контейнерах он будет автоматом настраивать проксирование. В некоторых ситуациях это очень удобно.
#webserver #traefik #devops
Я недавно написал 2 публикации на тему настройки мониторинга на базе Prometheus (1, 2). Они получились чуток недоделанными, потому что некоторые вещи всё же приходилось делать руками - добавлять Datasource и шаблоны. Решил это исправить, чтобы в полной мере раскрыть принцип IaC (инфраструктура как код). Плюс, для полноты картины, добавил туда в связку ещё и blackbox-exporter для мониторинга за сайтами. В итоге в пару кликов можно развернуть полноценный мониторинг с примерами стандартных конфигураций, дашбордов, оповещений.
Для того, чтобы более ясно представлять о чём тут пойдёт речь, лучше прочитать две первых публикации, на которые я дал ссылки. Я подготовил docker-compose и набор других необходимых файлов, чтобы автоматически развернуть базовый мониторинг на базе Prometheus, Node-exporter, Blackbox-exporter, Alert Manager и Grafana.
По просьбам трудящихся залил всё в Git репозиторий. Клонируем к себе и разбираемся:
Что есть что:
▪️
▪️
▪️
▪️
▪️
▪️
▪️
Скопировали репозиторий, пробежались по настройкам, что-то изменили под свои потребности. Запускаем:
Идём на порт сервера 3000 и заходим в Grafana. Учётка стандартная - admin / admin. Видим там уже 3 настроенных дашборда. На порту 9090 живёт сам Prometheus, тоже можно зайти, посмотреть.
Вот ссылки на шаблоны, которые я добавил. Можете посмотреть картинки, как это будет выглядеть. У Blackbox информативные дашборды. Уже только для них можно использовать эту связку, так как всё уже сделано за вас. Вам нужно будет только список сайтов заполнить в prometheus.yml.
⇨ Blackbox Exporter (HTTP prober)
⇨ Prometheus Blackbox Exporter
⇨ Node Exporter Full
Для того, чтобы автоматически доставлять все изменения в настройках на сервер мониторинга, можно воспользоваться моей инструкцией на примере gatus и gitlab-ci. Точно таким же подходом вы можете накатывать и изменения в этот мониторинг.
Мне изначально казалось, что подобных примеров уже много. Но когда стало нужно, не нашёл чего-то готового, чтобы меня устроило. В итоге сам набросал вот такой проект. Сделал в том числе и для себя, чтобы всё в одном месте было для быстрого развёртывания. Каждая отдельная настройка, будь то prometheus, alertmanager, blackbox хорошо гуглятся. Либо можно сразу в документацию идти, там всё подробно описано. Не стал сюда ссылки добавлять, чтобы не перегружать.
❗️Будьте аккуратны при работе с Prometheus и ему подобными, где всё состояние инфраструктуры описывается только кодом. После него будет трудно возвращаться к настройке и управлению Zabbix. Давно это ощущаю на себе. Хоть у них и сильно разные возможности, но IaC подкупает.
#prometheus #devops #мониторинг
Для того, чтобы более ясно представлять о чём тут пойдёт речь, лучше прочитать две первых публикации, на которые я дал ссылки. Я подготовил docker-compose и набор других необходимых файлов, чтобы автоматически развернуть базовый мониторинг на базе Prometheus, Node-exporter, Blackbox-exporter, Alert Manager и Grafana.
По просьбам трудящихся залил всё в Git репозиторий. Клонируем к себе и разбираемся:
# git clone https://gitflic.ru/project/serveradmin/prometheus.git# cd prometheusЧто есть что:
▪️
docker-compose.yml - основной compose файл, где описаны все контейнеры.▪️
prometheus.yml - настройки prometheus, где для примера показаны задачи мониторинга локального хоста, удалённого хоста с node-exporter, сайтов через blackbox.▪️
blackbox.yml - настройки для blackbox, для примера взял только проверку кодов ответа веб сервера. ▪️
alertmanager.yml - настройки оповещений, для примера настроил smtp и telegram▪️
alert.rules - правила оповещений для alertmanager, для примера настроил 3 правила - недоступность хоста, перегрузка по CPU, недоступность сайта.▪️
grafana\provisioning\datasources\prometheus.yml - автоматическая настройка datasource в виде локального prometheus, чтобы не ходить, руками не добавлять.▪️
grafana\provisioning\dashboards - автоматическое добавление трёх дашбордов: один для node-exporter, два других для blackbox.Скопировали репозиторий, пробежались по настройкам, что-то изменили под свои потребности. Запускаем:
# docker compose up -dИдём на порт сервера 3000 и заходим в Grafana. Учётка стандартная - admin / admin. Видим там уже 3 настроенных дашборда. На порту 9090 живёт сам Prometheus, тоже можно зайти, посмотреть.
Вот ссылки на шаблоны, которые я добавил. Можете посмотреть картинки, как это будет выглядеть. У Blackbox информативные дашборды. Уже только для них можно использовать эту связку, так как всё уже сделано за вас. Вам нужно будет только список сайтов заполнить в prometheus.yml.
⇨ Blackbox Exporter (HTTP prober)
⇨ Prometheus Blackbox Exporter
⇨ Node Exporter Full
Для того, чтобы автоматически доставлять все изменения в настройках на сервер мониторинга, можно воспользоваться моей инструкцией на примере gatus и gitlab-ci. Точно таким же подходом вы можете накатывать и изменения в этот мониторинг.
Мне изначально казалось, что подобных примеров уже много. Но когда стало нужно, не нашёл чего-то готового, чтобы меня устроило. В итоге сам набросал вот такой проект. Сделал в том числе и для себя, чтобы всё в одном месте было для быстрого развёртывания. Каждая отдельная настройка, будь то prometheus, alertmanager, blackbox хорошо гуглятся. Либо можно сразу в документацию идти, там всё подробно описано. Не стал сюда ссылки добавлять, чтобы не перегружать.
❗️Будьте аккуратны при работе с Prometheus и ему подобными, где всё состояние инфраструктуры описывается только кодом. После него будет трудно возвращаться к настройке и управлению Zabbix. Давно это ощущаю на себе. Хоть у них и сильно разные возможности, но IaC подкупает.
#prometheus #devops #мониторинг
Я в своё время, когда познакомился с CIS — Center for Internet Security, изучил некоторые их документы по настройке софта, с которым работаю. Вот список заметок:
▪️ Nginx
▪️ MySQL 5.7
▪️ Apache 2.4
▪️ Debian 11
▪️ Docker
▪️ Ubuntu 22.04 LTS
▪️ PostgreSQL 16
На основе документа CIS Docker Benchmark v1.6.0 (доступ только через VPN) создан open source продукт, который проверяет Docker контейнеры и настройки самой службы - Docker Bench for Security. Покажу, как им пользоваться.
Можно просто запустить скрипт на хосте и посмотреть его замечания и рекомендации:
Вот несколько замечаний, которые я получил на тестовом сервере. Это не всё, что там было, показываю просто для примера:
Вспоминаю разбор документа по докеру, там реально об этом идёт речь, что указано в замечаниях.
Похожую проверку можно запустить через Docker. Это тот же скрипт, но упакованный в контейнер, который тут же будет собран:
Проверки можно разделить и не делать сразу все. К примеру, запускаем только проверки образов и runtime:
Для проверки конкретного образа, достаточно его указать при запуске скрипта. Образ должен быть скачан. Будут выполнены все проверки, в том числе хоста. При проверке образа это скорее всего не нужно. Имеет смысл сразу указать, что нас интересует только 4-й раздел проверок, относящихся к образам:
Напомню, что есть похожий инструмент Dockle, писал про него. Он делает примерно то же самое, но только для образов. Саму систему и службу docker не проверяет. Конкретно для образов он удобнее и информативнее, чем Docker Bench for Security, потому что проверяет не только по CIS, но и некоторым другим рекомендациям. Увидеть разницу проверок можно на тестовом образе от Dockle:
У Dockle вывод более подробный с большим числом замечаний. Эти проверки имеет смысл использовать в тандеме. Docker Bench for Security для хоста и службы, Docker для образов.
#cis #docker #devops
▪️ Nginx
▪️ MySQL 5.7
▪️ Apache 2.4
▪️ Debian 11
▪️ Docker
▪️ Ubuntu 22.04 LTS
▪️ PostgreSQL 16
На основе документа CIS Docker Benchmark v1.6.0 (доступ только через VPN) создан open source продукт, который проверяет Docker контейнеры и настройки самой службы - Docker Bench for Security. Покажу, как им пользоваться.
Можно просто запустить скрипт на хосте и посмотреть его замечания и рекомендации:
# git clone https://github.com/docker/docker-bench-security.git# cd docker-bench-security# sh docker-bench-security.shВот несколько замечаний, которые я получил на тестовом сервере. Это не всё, что там было, показываю просто для примера:
[WARN] 1.1.1 - Ensure a separate partition for containers has been created[WARN] 1.1.3 - Ensure auditing is configured for the Docker daemon[WARN] 2.2 - Ensure network traffic is restricted between containers on the default bridge[WARN] 2.13 - Ensure centralized and remote logging is configured[WARN] 4.5 - Ensure Content trust for Docker is EnabledВспоминаю разбор документа по докеру, там реально об этом идёт речь, что указано в замечаниях.
Похожую проверку можно запустить через Docker. Это тот же скрипт, но упакованный в контейнер, который тут же будет собран:
# docker-compose run --rm docker-bench-securityПроверки можно разделить и не делать сразу все. К примеру, запускаем только проверки образов и runtime:
# sh docker-bench-security.sh -c container_images,container_runtime Для проверки конкретного образа, достаточно его указать при запуске скрипта. Образ должен быть скачан. Будут выполнены все проверки, в том числе хоста. При проверке образа это скорее всего не нужно. Имеет смысл сразу указать, что нас интересует только 4-й раздел проверок, относящихся к образам:
# docker image pull nginx# sh docker-bench-security.sh -i nginx -c container_imagesНапомню, что есть похожий инструмент Dockle, писал про него. Он делает примерно то же самое, но только для образов. Саму систему и службу docker не проверяет. Конкретно для образов он удобнее и информативнее, чем Docker Bench for Security, потому что проверяет не только по CIS, но и некоторым другим рекомендациям. Увидеть разницу проверок можно на тестовом образе от Dockle:
# docker run --rm goodwithtech/dockle:latest goodwithtech/dockle-test:v2# sh docker-bench-security.sh -i dockle-test -c container_imagesУ Dockle вывод более подробный с большим числом замечаний. Эти проверки имеет смысл использовать в тандеме. Docker Bench for Security для хоста и службы, Docker для образов.
#cis #docker #devops
Упустил момент с тем, что компания Gitlab ограничила доступ к своему репозиторию gitlab-ee. Не видел новостей на этот счёт. Но при этом остался доступ к репозиторию gitlab-сe. Поясню различия между этими версиями и репозиториями.
Gitlab позволяет развернуть свой продукт в так называемом режиме self-managed. То есть вы его берёте и ставите на свой сервер. Исходный код сервера открыт. У компании есть репозитории с пакетами под все популярные системы.
При этом существуют две редакции Gitlab:
▪️Community Edition
▪️Enterprise Edition
Редакция Community полностью с открытым исходным кодом. Можно брать и пользоваться. Enterprise построена на базе кода Community, но к ней добавлены возможности на основе закрытого кода. Эта дополнительная функциональность будет работать только если вы заплатите, либо запустите ознакомительную версию.
Таким образом, если для вас недопустимо разворачивать продукт, где присутствует код под проприетарной лицензией, то берите Community Edition. Переход с этой версии на платную невозможен. Нужно будет делать миграцию. Если же вам всё равно на наличие закрытого кода, то можно ставить Enterprise Edition. Без оплаты эта редакция будет работать так же, как и Community. Но если вы захотите воспользоваться платными дополнениями, то просто заплатите и будете пользоваться.
Для простоты и удобства Gitlab рекомендует всем ставить Enterprise Edition. Её пакеты лежат в репозитории https://packages.gitlab.com/gitlab/gitlab-ee. Доступ туда IP адресам из РФ закрыт. Потеря невелика, так как что-то купить всё равно не получится. А доступ к репозиторию с Community Edition открыт - https://packages.gitlab.com/gitlab/gitlab-ce. Оттуда можно выполнить установку. Выглядит это вот так:
Не забудьте указать свой url. Для теста можно использовать IP адрес, примерно так: http://10.20.1.36. Учётка для входа будет root, пароль в файле
Подобным образом вы без проблем можете развернуть бесплатную версию gitlab с открытым исходным кодом на своём сервере. Ни регистраций, ни чего-то ещё не требуется. Можно свободно пользоваться.
#gitlab #devops
Gitlab позволяет развернуть свой продукт в так называемом режиме self-managed. То есть вы его берёте и ставите на свой сервер. Исходный код сервера открыт. У компании есть репозитории с пакетами под все популярные системы.
При этом существуют две редакции Gitlab:
▪️Community Edition
▪️Enterprise Edition
Редакция Community полностью с открытым исходным кодом. Можно брать и пользоваться. Enterprise построена на базе кода Community, но к ней добавлены возможности на основе закрытого кода. Эта дополнительная функциональность будет работать только если вы заплатите, либо запустите ознакомительную версию.
Таким образом, если для вас недопустимо разворачивать продукт, где присутствует код под проприетарной лицензией, то берите Community Edition. Переход с этой версии на платную невозможен. Нужно будет делать миграцию. Если же вам всё равно на наличие закрытого кода, то можно ставить Enterprise Edition. Без оплаты эта редакция будет работать так же, как и Community. Но если вы захотите воспользоваться платными дополнениями, то просто заплатите и будете пользоваться.
Для простоты и удобства Gitlab рекомендует всем ставить Enterprise Edition. Её пакеты лежат в репозитории https://packages.gitlab.com/gitlab/gitlab-ee. Доступ туда IP адресам из РФ закрыт. Потеря невелика, так как что-то купить всё равно не получится. А доступ к репозиторию с Community Edition открыт - https://packages.gitlab.com/gitlab/gitlab-ce. Оттуда можно выполнить установку. Выглядит это вот так:
# curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | bash# EXTERNAL_URL="https://gitlab.example.com" apt-get install gitlab-ceНе забудьте указать свой url. Для теста можно использовать IP адрес, примерно так: http://10.20.1.36. Учётка для входа будет root, пароль в файле
/etc/gitlab/initial_root_password.Подобным образом вы без проблем можете развернуть бесплатную версию gitlab с открытым исходным кодом на своём сервере. Ни регистраций, ни чего-то ещё не требуется. Можно свободно пользоваться.
#gitlab #devops
⇨ GitLab CI/CD - Главные Основы создания CI/CD Pipeline
Хорошее обзорное видео с примерами построения CI/CD на базе Gitlab. Автор наглядно на конкретном примере всё показывает и рассказывает. Кто не знаком с этим каналом, рекомендую. Там в прошлом есть обучающие курсы из серии видео для базовых вещей в DevOps.
⇨ Restic - решение для твоих бекапов
Пример использования популярного решения для бэкапов - Restic. Это быстрый, функциональный инструмент для бэкапов, состоящий из одного бинарника на Go. Кто не знаком, рекомендую посмотреть на него. Там снэпшоты, дедупликация, проверка целостности, куча бэкендов в поддержке и т.д.
⇨ Разбор падения Reddit – как крупнейший форум оказался в ауте!
Автор рассказал про одно из крупных падений Reddit из-за неудачного обновления Kubernetes. А отката неудачного обновления там не предусмотрено.
⇨ Docker Container Monitoring Dashboards both Open Source and Netdata!
Автор рассмотрел наиболее популярные инструменты для мониторинга контейнеров: cAdviser, Prometheus, Grafana, Netdata. Нравится этот канал, хорошее качество видео.
⇨ Simple HTTPs for Docker! // Traefik Tutorial (updated)
Большое обзорное виде про Traefik. Не знаю, чем его так любят блогеры, но про этот обратный прокси для веб сайтов больше всего роликов. Этот, получается, самый свежий будет. Тут всё: установка, базовая настройка, динамическая конфигурация, метки для Docker, TLS сертификаты и т.д.
⇨ How To Monitor Windows Services with ZABBIX ( Correct Way )
Любой, кто мониторил Windows хосты с помощью Zabbix знает, как там неудобно реализован мониторинг служб. Будет масса бесполезных уведомлений. Лично я всегда отключаю автообнаружение служб. А если надо что-то мониторить, настраиваю отдельно вручную. Автор показывает, как можно не отключая мониторинг всех служб, сделать исключение для некоторых из них. По мне, так сделано очень неудобно. Но пока других простых решений нет.
⇨ САМОПОДПИСАННЫЕ SSL СЕРТИФИКАТЫ ДЛЯ ДОМА.
Наглядное видео, как создать и использовать самоподписные сертификаты. В видео кратко рассмотрена теория по TLS, что содержат сертификаты, что такое цепочки доверия и т.д. Сертификаты автор выпускал с помощью XCA - локального приложения для управления сертификатами. Краткая инструкция по этой теме была у меня на канале. Рекомендую для быстрого копипаста в консоли.
⇨ Настройки WAF на Cloudflare для домашнего сервера
Обзор WAF на бесплатном тарифе от Cloudflare. Он, на удивление, не вводил никаких санкций и по-прежнему работает. Не знаю, насколько оправданно им сейчас пользоваться. Я буквально пару недель назад последнего пользователя отключил от CF. Просто на всякий случай. Никаких проблем в его работе не было. Хорошее бесплатное решение, чтобы скрыть реальные адреса своего проекта.
⇨ ASUS NUC 14 Pro Review // Best Intel NUC for Home Lab?
Обзор небольших minipc. Лично мне всегда нравились нюки за их компактный размер и хорошую производительность. Мечтаю себе купить 3 таких штуки для домашнего кластера, но всё время откладываю, потому что дома полно старого железа. Большой нужды в них нет, поэтому жалко денег. Их не назвать бюджетными устройствами, так как стоят больше аналогов. На авито много предложений за 70к+ р.
⇨ Нейросеть + 1С. RAG системы для бизнеса
Пример того, как может работать нейросеть в связке с БД интернет-магазина, чтобы отвечать на вопросы пользователей на основе актуальной информации. Смотрю подобные ролики просто из любопытства, чтобы иметь представление, как всё это работает.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
GitLab CI/CD - Главные Основы создания CI/CD Pipeline
#devops #gitlab #девопс
https://gitlab.com/adv4000/myproject1
Если помог, поддержите парой баксов, даже Канадских :)
Boosty: https://boosty.to/adv-it/donate
PayPal: https://www.paypal.me/DenisAstahov
https://gitlab.com/adv4000/myproject1
Если помог, поддержите парой баксов, даже Канадских :)
Boosty: https://boosty.to/adv-it/donate
PayPal: https://www.paypal.me/DenisAstahov
Вчера в комментариях посоветовали удобную программу для просмотра серверных логов браузером. Сразу попробовал - очень понравилась утилита. Речь пойдёт про logdy. Это одиночный бинарник на Go. Установить можно так:
Скрипт на один экран, который просто определяет версию системы и скачивает скомпилированный бинарник из github. Можно и вручную скачать.
Использовать logdy можно в разных режимах. Самый простой - отправить в него через пайп содержимое лога:
По умолчанию он стартует на localhost, поэтому я принудительно через ключ запустил его на всех интерфейсах. Если не указать порт, то он запустится на 8080. Можно идти по IP адресу сервера на порт 8080 и смотреть в браузере содержимое лога syslog. Можно то же самое сделать вот так:
Вообще, эта штука придумана в первую очередь для разработчиков. В блоге авторов есть пример использования во время локальной разработки. Допустим, вы у себя на машине запускаете проект под node.js:
Далее перемещаетесь в VS Code, открываете через консоль команд (Ctrl+Shift+P) "Simple Browser: Show" и там указываете адрес веб интерфейса. Для локальной разработки это будет http://localhost:8080. Таким образом вы в одном месте можете править код, перезапускать приложение и тут же видеть его логи.
То же самое можно делать для Docker контейнеров:
И погнали смотреть логи контейнера. Можно объединить разные контейнеры или логи. Делается это следующим образом:
Запустили logdy в режиме сокетов, на которые он принимает логи и отображает в веб интерфейсе. И отправили каждый контейнер в свой сокет. В веб интерфейсе можно как вместе смотреть эти логи, так и разделять по сокетам.
У logdy даже API есть для отправки туда логов с аутентификацией по токену. Выглядит это примерно так. Запускаем logdy с api:
Отправляем в него логи:
В веб интерфейс прилетит этот лог. В него можно stdin отправить:
У logdy хорошая подробная документация, где описаны все ключи CLI и приведены примеры разных режимов работы и использования. Такой небольшой, нишевый, удобный продукт. Через ключи запуска веб интерфейс можно закрыть паролем.
Рекомендую взять на заметку. Иногда хочется открыть какой-то лог или логи в браузере. Через logdy это удобно сделать. Он может не только отобразить логи, но и сразу распарсить их, разбить на колонки, сделать какую-то сортировку и т.д. В документации есть примеры. На картинке ниже показано, как он распарсил лог веб севрера в формате json.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
⇨ Сайт / Исходники / Demo
#logs #devops
# curl https://logdy.dev/install.sh | shСкрипт на один экран, который просто определяет версию системы и скачивает скомпилированный бинарник из github. Можно и вручную скачать.
Использовать logdy можно в разных режимах. Самый простой - отправить в него через пайп содержимое лога:
# tail -f /var/log/syslog | logdy --ui-ip=0.0.0.0По умолчанию он стартует на localhost, поэтому я принудительно через ключ запустил его на всех интерфейсах. Если не указать порт, то он запустится на 8080. Можно идти по IP адресу сервера на порт 8080 и смотреть в браузере содержимое лога syslog. Можно то же самое сделать вот так:
# logdy --ui-ip=0.0.0.0 follow /var/log/syslogВообще, эта штука придумана в первую очередь для разработчиков. В блоге авторов есть пример использования во время локальной разработки. Допустим, вы у себя на машине запускаете проект под node.js:
# node app.js | logdyДалее перемещаетесь в VS Code, открываете через консоль команд (Ctrl+Shift+P) "Simple Browser: Show" и там указываете адрес веб интерфейса. Для локальной разработки это будет http://localhost:8080. Таким образом вы в одном месте можете править код, перезапускать приложение и тут же видеть его логи.
То же самое можно делать для Docker контейнеров:
# docker logs 761965fa13b2 --follow | logdy --ui-ip=0.0.0.0И погнали смотреть логи контейнера. Можно объединить разные контейнеры или логи. Делается это следующим образом:
# logdy --ui-ip=0.0.0.0 socket 8123 8124# docker logs d20339949095 --follow | logdy forward 8123# docker logs 761965fa13b2 --follow | logdy forward 8124Запустили logdy в режиме сокетов, на которые он принимает логи и отображает в веб интерфейсе. И отправили каждый контейнер в свой сокет. В веб интерфейсе можно как вместе смотреть эти логи, так и разделять по сокетам.
У logdy даже API есть для отправки туда логов с аутентификацией по токену. Выглядит это примерно так. Запускаем logdy с api:
# logdy --ui-ip=0.0.0.0 --api-key=secrettokenОтправляем в него логи:
curl --location --request POST 'http://1.2.3.4:8080/api/log' \--header 'Authorization: Bearer secrettoken' \--header 'Content-Type: application/json' \--data '{"logs": [{"log": "this is a log message as a string" }],"source":"machine identifier"}'В веб интерфейс прилетит этот лог. В него можно stdin отправить:
# logdy stdinУ logdy хорошая подробная документация, где описаны все ключи CLI и приведены примеры разных режимов работы и использования. Такой небольшой, нишевый, удобный продукт. Через ключи запуска веб интерфейс можно закрыть паролем.
Рекомендую взять на заметку. Иногда хочется открыть какой-то лог или логи в браузере. Через logdy это удобно сделать. Он может не только отобразить логи, но и сразу распарсить их, разбить на колонки, сделать какую-то сортировку и т.д. В документации есть примеры. На картинке ниже показано, как он распарсил лог веб севрера в формате json.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
⇨ Сайт / Исходники / Demo
#logs #devops
Неоднократно видел в комментариях и обсуждениях Ceph упоминание о VitaStor. Автор называет её быстрой и простой распределённой программной СХД. Архитектурно она сильно похожа на Ceph, так что если кто-то с ней знаком, попробовать Vitastor не составит труда. Я где-то за пару часов разобрался, настроил тестовый стенд и проверил в работе.
Сразу дам ссылку на выступление автора, где он подробно рассказывает об истории создания VitaStor. В первой половине презентации он делает обзор современных кластерных средств хранения данных. В целом всё выступление интересное, я целиком прослушал без ускорения.
▶️ Vitastor, или Как я написал свою хранилку
В сети мало информации про VitaStor, а сравнительных тестов так вообще почти нет. Есть от самого автора, он их приводит в выступлении. И есть статья на хабре от небезызвестного Kvaps, где он сравнивает разные распределённые хранилища: Linstor, Ceph, Mayastor и Vitastor. По этим имеющимся данным VitaStor значительно быстрее Ceph при схожих моделях использования. По сути это прямой аналог, который можно просто взять и поставить вместо Ceph.
Автор VitaStor - наш соотечественник, так что документация проста и понятна для русского человека. Я не буду приводить подробно все команды для установки и использования, потому что они не уместятся в заметке. Дам только ссылки из документации, по которым я делал. Больше никаких источников не использовал. Установка очень простая.
Сразу упомяну, что у VitaStor есть готовые плагины для использования с современными системами виртуализации и контейнеризации: Proxmox, OpenStack, Kubernetes CSI.
Основное предназначение VitaStor - сетевые блочные устройства для систем виртуализации. То есть это в первую очередь кластер для дисков виртуалок. По аналогии с CephFS есть кластерная файловая система VitastorFS. В планах обозначено объектное хранилище S3 - Vitastor S3.
Я взял тестовый кластер из 3-х виртуальных машин под ОС Debian 12. В каждую из них добавил по 2 виртуальных диска. Один под систему, второй под сетевое хранилище. Зашёл в раздел установка из пакетов и выполнил установку.
Далее пошёл в раздел быстрый старт и собрал кластер практически в режиме копирования и вставки. Порядок действий следующий:
1️⃣ Настраиваем мониторы на основе etcd. Аналог MON в Ceph.
2️⃣ Настраиваем OSD (Object Storage Device). В Ceph так же называется.
3️⃣ Создаём пул.
4️⃣ Создаём образ диска.
Процедура 1 в 1 как с Ceph. Дальше я немного замешкался, так как не понял, как теперь подключать созданный диск. Можно было создать VitastorFS, но мне хотелось именно блочные устройства попробовать.
Немного походил по документации и разобрался. Автор пишет, что лучший интерфейс для подключения дисков к системе - VDUSE (vDPA Device in Userspace), так как поддерживается на уровне ядра и работает в целом быстрее, чем что либо другое. Альтернатива - NBD.
Я подключил диск через VDUSE. Он поддерживается ядром, начиная с версии 5.15, но только в 6.6 и выше модуль ядра включён по умолчанию. На Debian 12 сейчас ядро 6.1, так что модуль пришлось собирать вручную по инструкции. Получилось всё без особых проблем простым копированием команд. В итоге подключил диск и получил блочное устройство
Немного погонял тесты, но толку от них никаких, так как собрано всё было в рамках одного сервера на виртуальных машинах. Никаких сравнительных тестов с другими системами хранения тоже не проводил, так как это трудоёмкая задача.
Отмечу для тех, кому это важно. Vitastor есть в реестре российского программного обеспечения. Можно без проблем использовать в рамках импортозамещения.
Ещё ссылка на интересное выступление автора, где он рассказывает про архитектуру:
▶️ Архитектура Vitastor. Тёмная сторона моей распределённой СХД
Продукт, конечно интересный. Понравился комментарий автора по поводу производительности Ceph. Он предполагает, что ускорить его невозможно, так как там более миллиона строк кода. Проще написать с нуля, что он и сделал.
⇨ Сайт / Исходники
#ceph #fileserver #devops #отечественное
Сразу дам ссылку на выступление автора, где он подробно рассказывает об истории создания VitaStor. В первой половине презентации он делает обзор современных кластерных средств хранения данных. В целом всё выступление интересное, я целиком прослушал без ускорения.
▶️ Vitastor, или Как я написал свою хранилку
В сети мало информации про VitaStor, а сравнительных тестов так вообще почти нет. Есть от самого автора, он их приводит в выступлении. И есть статья на хабре от небезызвестного Kvaps, где он сравнивает разные распределённые хранилища: Linstor, Ceph, Mayastor и Vitastor. По этим имеющимся данным VitaStor значительно быстрее Ceph при схожих моделях использования. По сути это прямой аналог, который можно просто взять и поставить вместо Ceph.
Автор VitaStor - наш соотечественник, так что документация проста и понятна для русского человека. Я не буду приводить подробно все команды для установки и использования, потому что они не уместятся в заметке. Дам только ссылки из документации, по которым я делал. Больше никаких источников не использовал. Установка очень простая.
Сразу упомяну, что у VitaStor есть готовые плагины для использования с современными системами виртуализации и контейнеризации: Proxmox, OpenStack, Kubernetes CSI.
Основное предназначение VitaStor - сетевые блочные устройства для систем виртуализации. То есть это в первую очередь кластер для дисков виртуалок. По аналогии с CephFS есть кластерная файловая система VitastorFS. В планах обозначено объектное хранилище S3 - Vitastor S3.
Я взял тестовый кластер из 3-х виртуальных машин под ОС Debian 12. В каждую из них добавил по 2 виртуальных диска. Один под систему, второй под сетевое хранилище. Зашёл в раздел установка из пакетов и выполнил установку.
Далее пошёл в раздел быстрый старт и собрал кластер практически в режиме копирования и вставки. Порядок действий следующий:
Процедура 1 в 1 как с Ceph. Дальше я немного замешкался, так как не понял, как теперь подключать созданный диск. Можно было создать VitastorFS, но мне хотелось именно блочные устройства попробовать.
Немного походил по документации и разобрался. Автор пишет, что лучший интерфейс для подключения дисков к системе - VDUSE (vDPA Device in Userspace), так как поддерживается на уровне ядра и работает в целом быстрее, чем что либо другое. Альтернатива - NBD.
Я подключил диск через VDUSE. Он поддерживается ядром, начиная с версии 5.15, но только в 6.6 и выше модуль ядра включён по умолчанию. На Debian 12 сейчас ядро 6.1, так что модуль пришлось собирать вручную по инструкции. Получилось всё без особых проблем простым копированием команд. В итоге подключил диск и получил блочное устройство
/dev/vda. Немного погонял тесты, но толку от них никаких, так как собрано всё было в рамках одного сервера на виртуальных машинах. Никаких сравнительных тестов с другими системами хранения тоже не проводил, так как это трудоёмкая задача.
Отмечу для тех, кому это важно. Vitastor есть в реестре российского программного обеспечения. Можно без проблем использовать в рамках импортозамещения.
Ещё ссылка на интересное выступление автора, где он рассказывает про архитектуру:
▶️ Архитектура Vitastor. Тёмная сторона моей распределённой СХД
Продукт, конечно интересный. Понравился комментарий автора по поводу производительности Ceph. Он предполагает, что ускорить его невозможно, так как там более миллиона строк кода. Проще написать с нуля, что он и сделал.
⇨ Сайт / Исходники
#ceph #fileserver #devops #отечественное
Please open Telegram to view this post
VIEW IN TELEGRAM
На днях нужно было вытащить один файл из Docker образа. Не из контейнера, а именно образа, так как не хотелось запускать контейнер. Никак не мог сообразить, как это сделать. Помню, что уже когда-то ломал над этим голову, и там почему-то нет простого решения. По крайней мере я его не знаю.
Решение такое. Образ надо скачать, создать контейнер, но не запускать его.
Теперь можно забрать нужный файл:
Либо выгрузить всё содержимое образа:
Заодно расскажу про один полезный инструмент, который рекомендую сохранить тем, кто работает с Docker. Dive - небольшая утилита на Go, которая позволяет просматривать слои образов и видеть, в каком слое что добавилось. У утилиты простой и наглядный tui интерфейс.
Можно скачать бинарник dive из репозитория или запустить сразу в докере и посмотреть нужный тебе образ:
Увидите структуру файловой системы с подсветкой цветом разных слоёв. Если постоянно работаете на своей машине с образами, сделайте alias:
Теперь можно просматривать образы так:
Удобная штука. Помимо отображения слоёв, она умеет проверять, не раздут ли размер образа из-за неправильных инструкций для сборки. Для этого можно собрать образ с помощью dive и сразу же получить результат анализа. То есть вместо docker build делаем dive build и получаем оценку. Подобную проверку можно встроить в CI систему и выполнять автоматически. В репозитории приведены примеры.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops
Решение такое. Образ надо скачать, создать контейнер, но не запускать его.
# docker pull nginx:latest# docker create --name nginx nginx:latestТеперь можно забрать нужный файл:
# docker cp nginx:/docker-entrypoint.d/30-tune-worker-processes.sh ~/Либо выгрузить всё содержимое образа:
# docker export nginx -o ~/nginx-docker.tar.gzЗаодно расскажу про один полезный инструмент, который рекомендую сохранить тем, кто работает с Docker. Dive - небольшая утилита на Go, которая позволяет просматривать слои образов и видеть, в каком слое что добавилось. У утилиты простой и наглядный tui интерфейс.
Можно скачать бинарник dive из репозитория или запустить сразу в докере и посмотреть нужный тебе образ:
# docker run -ti --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive nginx:latestУвидите структуру файловой системы с подсветкой цветом разных слоёв. Если постоянно работаете на своей машине с образами, сделайте alias:
alias dive="docker run -ti --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive"Теперь можно просматривать образы так:
# dive nginx:latestУдобная штука. Помимо отображения слоёв, она умеет проверять, не раздут ли размер образа из-за неправильных инструкций для сборки. Для этого можно собрать образ с помощью dive и сразу же получить результат анализа. То есть вместо docker build делаем dive build и получаем оценку. Подобную проверку можно встроить в CI систему и выполнять автоматически. В репозитории приведены примеры.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops
На прошлой неделе посмотрел видео про современную и функциональную open source платформу для управления веб приложениями, запускаемыми в Docker контейнерах. Речь пойдёт про Coolify. Вот видео, о котором я говорю:
▶️ Coolify - deploy services locally, or on remote servers!
Не стал его включать в регулярную подборку, потому что решил развернуть и попробовать систему, а потом отдельно про неё написать. Сейчас это сделаю.
Для того, чтобы сразу было понятно, что такое Coolify, скажу, что это условный аналог известного сервиса Heroku. Конечно, не такой функциональный, но он и появился не так давно. При этом на github у него огромное количество звёзд (34k), много спонсоров, большое сообщество и регулярные обновления. Проект монетизируется за счёт облачной версии.
Поясню своими словами, как работает Coolify. Условно её можно сравнить с панелью управления хостингом или VPS, только тут конечные сущности - приложения, запускаемые в контейнерах.
Вы разворачиваете панель и добавляете в неё следующие объекты:
▪️чистые сервера на базе Linux, которыми coolify управляет по ssh;
▪️s3 хранилища;
▪️git репозитории с вашим кодом;
▪️проекты, которые могут состоять из разных окружений (dev, prod и т.д.)
▪️переменные, ключи и токены;
▪️команды и пользователей
После этого вы идёте в один из проектов и создаёте там новый ресурс в виде вашего приложения, запущенного из готового образа, из Dockerfile или Docker-compose. Связываете это приложение, если необходимо, с соответствующим репозиторием кода, публикуете его на одном из добавленных серверов. Настраиваете к нему доступ по отдельному доменному имени. Для этого Coolify поднимает свой обратный прокси на базе Caddy или Traefik, получает сертификаты от Let's Encrypt.
Вы всем этим управляете из общего веб интерфейса с дашбордами. Все проекты и приложения, соответственно, бьются на команды с разными правами доступа. Помимо ваших приложений, подобным образом можно разворачивать популярные СУБД или преднастроенные сервисы на базе образов от linuxserver.io.
Проект довольно навороченный. Там много всего добавлено. Есть API, аутентификация через различных OAuth провайдеров, публикация ваших приложений через какой-то dyndns сервис, вебхуки, оповещения. Есть возможность подключаться к консоли серверов и контейнеров. Можно не ходить напрямую по ssh, а всем управлять через веб панель.
Даже не знаю, с чем Coolify сравнить. Не припоминаю похожих проектов. Он интересен и для личной инфраструктуры, если у вас большой набор своих сервисов, и для каких-то команд, особенно разработчиков. Можно всё для них автоматизировать и дать доступ. Они и консоли, и логи, и бэкапы своих приложений увидят. Смогут всем этим управлять, к примеру, в dev окружении и только смотреть в prod.
❗️Отдельно подчеркну ещё раз. Всё это только для Docker контейнеров. Деплоить что-то в обычное окружение Linux нельзя. Coolify автоматом на все добавляемые сервера устанавливает Docker.
⇨ 🌐 Сайт (через VPN) / 4️⃣ Исходники / Скриншоты интерфейса
#docker #devops #cicd
▶️ Coolify - deploy services locally, or on remote servers!
Не стал его включать в регулярную подборку, потому что решил развернуть и попробовать систему, а потом отдельно про неё написать. Сейчас это сделаю.
Для того, чтобы сразу было понятно, что такое Coolify, скажу, что это условный аналог известного сервиса Heroku. Конечно, не такой функциональный, но он и появился не так давно. При этом на github у него огромное количество звёзд (34k), много спонсоров, большое сообщество и регулярные обновления. Проект монетизируется за счёт облачной версии.
Поясню своими словами, как работает Coolify. Условно её можно сравнить с панелью управления хостингом или VPS, только тут конечные сущности - приложения, запускаемые в контейнерах.
Вы разворачиваете панель и добавляете в неё следующие объекты:
▪️чистые сервера на базе Linux, которыми coolify управляет по ssh;
▪️s3 хранилища;
▪️git репозитории с вашим кодом;
▪️проекты, которые могут состоять из разных окружений (dev, prod и т.д.)
▪️переменные, ключи и токены;
▪️команды и пользователей
После этого вы идёте в один из проектов и создаёте там новый ресурс в виде вашего приложения, запущенного из готового образа, из Dockerfile или Docker-compose. Связываете это приложение, если необходимо, с соответствующим репозиторием кода, публикуете его на одном из добавленных серверов. Настраиваете к нему доступ по отдельному доменному имени. Для этого Coolify поднимает свой обратный прокси на базе Caddy или Traefik, получает сертификаты от Let's Encrypt.
Вы всем этим управляете из общего веб интерфейса с дашбордами. Все проекты и приложения, соответственно, бьются на команды с разными правами доступа. Помимо ваших приложений, подобным образом можно разворачивать популярные СУБД или преднастроенные сервисы на базе образов от linuxserver.io.
Проект довольно навороченный. Там много всего добавлено. Есть API, аутентификация через различных OAuth провайдеров, публикация ваших приложений через какой-то dyndns сервис, вебхуки, оповещения. Есть возможность подключаться к консоли серверов и контейнеров. Можно не ходить напрямую по ssh, а всем управлять через веб панель.
Даже не знаю, с чем Coolify сравнить. Не припоминаю похожих проектов. Он интересен и для личной инфраструктуры, если у вас большой набор своих сервисов, и для каких-то команд, особенно разработчиков. Можно всё для них автоматизировать и дать доступ. Они и консоли, и логи, и бэкапы своих приложений увидят. Смогут всем этим управлять, к примеру, в dev окружении и только смотреть в prod.
❗️Отдельно подчеркну ещё раз. Всё это только для Docker контейнеров. Деплоить что-то в обычное окружение Linux нельзя. Coolify автоматом на все добавляемые сервера устанавливает Docker.
⇨ 🌐 Сайт (через VPN) / 4️⃣ Исходники / Скриншоты интерфейса
#docker #devops #cicd
⇨ GitLab CI/CD - Полный DevOps Pipeline с НУЛЯ, Создание Docker Image и деплой в AWS Lambda
⇨ GitLab - Как работать используя TOKEN
Продолжение начатой ранее автором темы про Gitlab и CI/CD на его основе. Если самостоятельно изучаете эту тему, то видео будут отличным подспорьем. Автор хорошо объясняет, показывает на примерах.
⇨ KEYNOTE by Alexei Vladishev / Zabbix Summit 2024
У Zabbix недавно прошёл масштабный саммит. Они выложили на своём канале кучу видео оттуда. Посмотрите, может вас заинтересуют какие-то темы. Мне очень хочется некоторые видео посмотреть и разобрать, но не знаю, найду ли для этого время. Хотя бы посмотреть надо для начала. Там и мониторинг MariaDB, и новый веб мониторинг, и самописные проверки по tcp, и мониторинг DNS, и тюнинг производительности, и т.д. В общем, интересно.
⇨ Proxmox Network. Обзор и настройка. Bridge, Bond, VLAN.
Очень подробное наглядное видео с картинками и схемами по организации виртуальной сети в Proxmox. Рассмотрены не только тривиальные случаи. Например, автор рассказал, как настроить две изолированные подсети виртуалок, в которой каждая подсеть выходит в инет через свой роутер. Там же он создаёт и тестирует Bond - объединение сетевых адаптеров для отказоустойчивости.
⇨ Настройка мониторинга c помощью Grafana InfluxDB Prometheus Telegraf
Большое видео на тему установки и настройки указанного стэка. Я похожий стэк тестировал и писал об этом: TICK Stack. Из своих изысканий не особо понял, зачем нужно использовать Telegraf и InfluxDB. Из плюсов только то, что это и метрики, и логи в одном месте. Но сейчас есть Loki для этого, и я бы отдал предпочтение ему.
⇨ Какой софт у меня в моей homelab в 2024
Интересно было посмотреть, как всё организовано у автора. У него один общий сервер под Proxmox и там виртуалки с контейнерами: opnsense, truenas, pbs, pi-hole, nut, homapage, plex, sonarr, nextcloud и т.д. Он рассказал не только про софт, но и про организацию сети. Почти по всему софту у него есть отдельные ролики.
⇨ Best Docker Update Image Tools for Automating Container Updates
Обзор софта, который умеет автоматически обновлять образы контейнеров: Watchtower, Shepherd, Portainer, CI/CD pipelines.
⇨ Как быстро определить версию дистрибутива Linux и эффективно управлять пакетами?
Небольшое справочное видео по теме. Заголовок немного некорректно подобран, так как в видео в основном про пакеты речь идёт, а про версию ОС в самом начале. Автор предлагает смотреть так:
cat /etc/*release. Я лично привык использовать hostnamectl. Так не только ОС видно, но тип виртуализации и некоторую другую информацию. ⇨ Reacting to your CURSED Homelab Setups
Длинное развлекательное видео, где автор показывает и обсуждает домашние лаборатории своих пользователей. Ранее он просил прислать картинки и описание своих домашних лабораторий, а теперь обработал всё это и оформил в видео.
⇨ How To Rebrand Zabbix 7.0 ( Replace Logos )
Небольшое обзорное видео на тему брендирования своего сервера Zabbix с заменой логотипа.
⇨ MiniTool ShadowMaker - простая и бесплатная программа для бекапа и восстановления системы
Рекламный обзор небольшой бесплатной версии программы для бэкапа ОС Windows. У программы, соответственно, есть и коммерческая версия. На вид вроде ничего особенного по сравнению с другими подобными программами. Посмотрите, может вам приглянется.
В подписках было много видео с рекламой различных продуктов, типа того, что выше. Понимал об этом по UTM меткам в ссылках с описанием. При этом сами блогеры явно не говорят, что публикуют оплаченный рекламный обзор. Это как-то некрасиво. Привык уже к нашему закону о рекламе, где блогеров обязали маркировать и явно указывать, что они публикуют рекламу. Для конечного пользователя это большой плюс.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
GitLab CI/CD - Полный DevOps Pipeline с НУЛЯ, Создание Docker Image и деплой в AWS Lambda
#devops #gitlab #девопс
https://gitlab.com/adv4000/myproject2
Если помог, поддержите парой баксов, даже Канадских :)
Boosty: https://boosty.to/adv-it/donate
PayPal: https://www.paypal.me/DenisAstahov
https://gitlab.com/adv4000/myproject2
Если помог, поддержите парой баксов, даже Канадских :)
Boosty: https://boosty.to/adv-it/donate
PayPal: https://www.paypal.me/DenisAstahov