Pull to refresh
27
0
andrey i. mavlyanov @aim

Системный администратор

Send message

Спасибо, теперь я знаю как называть телек разговаривая с Алисой.

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

Нормальные люди и сейчас делают ранеры с типом docker machine и не извращаются созданием собственных костылей.
Вот дока гитлаба:
https://docs.gitlab.com/runner/configuration/autoscale.html
Вот офф плагин для ЯО:
https://github.com/yandex-cloud/docker-machine-driver-yandex

ip -s link show

добавлю от себя что еще есть утилита bridge в составе iproute2, если работаете с бриджами - мастхев (особенно чтобы смотреть bridge fdb).

Непонимание Docker идёт от узости кругозора, а также от биологического нежелания тратить энергию на обучение.

Я сам одно время считал, что докер не нужОн.

Когда у вас пара языков и пара проектов, не проблем настроить это на компьютере один раз. И написать себе инструкцию, которая пригодится в случае если придётся переходить на другой сервер или переустанавливать систему, что случается не часто. Поэтому докер тут непонятно зачем. Учить долго, а выгода неочевидна. Но совершенно другое дело, когда требуется смотреть несколько проектов в день. Они написаны под разные языки, используют разные базы и элементы окружения и их версии. Без докера, настройка всего этого по инструкциям или даже баш скриптами превращается в ад. А с докером docker up и всё работает. То же самое с Ansible, его удобство понимаешь на десятом поднятом VPS. То же самое с Terraform. Он оказывается очень нужен, когда проходишь не первый переезд на другой хостинг или настройку большой системы.

Это, как сваи у дома или берега, одетые в гранит. Пока нет наводнения кажется, что не нужно.

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

Современный стек для web:

  • iOS + Android native или Flutter в зависимости от сложности приложения и бюджета

  • Фронт на React или Vue. Предпочитаю первое

  • Kuber для возможных задач роста, даже если сервер один

  • Terraform для поднятия VPS. Не руками же, как австралопитек

  • Ansible для первичной настройки VPS, например для установки того же Docker

  • Репозиторий с CI/CD скриптами, чтобы не залезать на сервер в консоль вообще, а также гонять тесты и делать сборки. Предпочитаю Gitea + Drone или GitHub + GitHub actions

  • Traefik для работы с поддоменами

  • Graylog или Logstash, не на сервере ж в консольке логи читать

  • VictoriaMetrics - улучшенный аналог Prometheus для сбора внутренних метрик

  • Пачка экспортеров для VictoriaMetrics

  • Grafana с пачкой дашбордов

  • SonarQube и линтеры для автоматической проверки качества кода

  • Kafka для очередей. Не синхронно же те же письма отправлять

  • Hugo и аналоги для генерации документации в HTML. Можно просто md хранить, но это неудобно читать. Можно Confluence, Wiki на своём сервере. Облака, тот же Notion - нет. Как с них бэкапы автоматически делать?

  • Jira и минимум дашбордов: сгорание денег, выполненные сторипоинты, информация о деполоях и релизах, баги открытые и закрытые, информация о бэклоге и его изменении, количество кода и тестов, подтягивание из репозитория. Иначе вы будете, как дикарь объяснять команде/начальнику/инвесторам/себе почему так долго, и что делали словами.

  • Google Analytics, Яндекс Метрика или self hosted решение

  • Бэкапы при помощи rsync или restic в зависимости от типа данных

Это база. Инструментов может быть больше, но без любого из этих инструментов вы лишаете себя либо надёжности либо удобства.

Плюсом, надо изучать современные инструменты разработки. Я до сих пор наблюдаю, как люди печатают, глядя на клавиатуру, не пользуются алиасами, не знают про git commit convention, сидят в bash, вместо zsh, пишут в Eclipse и так далее. Мозг сохраняет почти ту же скорость обучения в 50 лет, что и в 20. После 50 идёт снижение, но не критическое. За пруфами ищите графики синаптогенеза у взрослых. Так что не надо прикрывать возрастом нежелание учиться или интеллектуальную слабость.

Инфраструктура настраивается не один месяц. Да, это нужно делать даже для простых проектов. Да, это нужно делать даже если работаешь один.

По началу вам может казаться, что это избыточно. Но потом когда большая часть сконфигурирована, технологии знакомы и всё делается парой команд, вам даже сайт визитку некомфортно будет делать без обвязки. Захотите логи NGINX посмотреть, а удобного инструмента нет :/

Дело было давно, по воспоминаниям коллег - он хотел слишком много RAM. Объемы данных не подскажу, но это не главное: когда проявились проблемы, мы решили особо не вкладываться в тюнинг инфлюкса, потому поняли, что мы не можем сделать high availability - что-то было доступно только в платной версии (репликация вроде бы). Поэтому решили дать ему умереть и переехать на Prometheus. Хотя если как минимум следить за кардинальностью, можно было бы жить дальше.

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

Основные НПА такие:
ФЗ от 27.07.2006 N149-ФЗ, статья 10.1
ПП от 26.06.2018 N728
ПП от 23.09.2020 N1526
Приказ ФСБ от 19.07.2016 N432
Приказ Минцифры от 29.10.2018 N571

В целом -- регулятор в времени, приближенном к реальному получает информацию о пользователях (IP, телефоны, всё что сервис запрашивает), их авторизации, созданном ими контенте и финансовых транзакциях.

Плюс, даже если в этих транзакциях нет информации о, допустим, составе заказа (поездки, товары), то я бы не стал, скажем так, надеяться на защиту TLS (HTTPS) между вами и ОРИ, поскольку ОРИ должен предоставить регулятору механизм дешифрования сообщений (см. приказ 432), а уже существующие средства СОРМ позволяют этому же регулятору записывать трафик... думаю вы можете сложить 2 и 2.

Пользуясь случаем хочу выразить огромную благодарность авторам Far2l ! Как оказалось, для меня отсутствие Far под линукс было единственным припятсявием к переходу на десктопе на постоянную работу в ubuntu. Уже несколько лет пользуюсь и не могу нарадоваться! Респект!

Вот пример моего конфига с которым ssllabs.com дает A+
listen                      443 ssl spdy;
ssl                         on;
ssl_protocols               TLSv1.2 TLSv1.1 TLSv1;
ssl_session_cache           shared:SSL:20m;
ssl_session_timeout         10m;
ssl_ciphers                 'EECDH+ECDSA+AESGCM:AES128+EECDH:AES128+EDH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!CAMELLIA:!ADH';
ssl_prefer_server_ciphers   on;

resolver                    8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout            10s;
add_header                  X-Frame-Options             "DENY";
add_header                  X-Content-Type-Options      "nosniff";
add_header                  Strict-Transport-Security   "max-age=31536000";
add_header                  Public-Key-Pins 'pin-sha256="[SOME_BASE64]"; max-age=5184000;';  #[SOME_BASE64] надо выставлять свое, гуглить как считать Public-Key-Pins
ssl_stapling            on;
ssl_trusted_certificate /etc/nginx/ssl/[SITE]/trustchain.pem;
ssl_certificate         /etc/nginx/ssl/[SITE]/server.crt;
ssl_certificate_key     /etc/nginx/ssl/[SITE]/server.key;
ssl_dhparam             /etc/nginx/ssl/[SITE]/dh.pem;        #openssl dhparam 2048 -out dh.pem
Описание в RFC 974, RFC 1034

Для сопротивляющихся, разжёвано в RFC 1912:
A CNAME record is not allowed to coexist with any other data.  In
   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
   can't also have an MX record for suzy.podunk.edu, or an A record, or
   even a TXT record.  Especially do not try to combine CNAMEs and NS
   records like this!:

           podunk.xx.      IN      NS      ns1
                           IN      NS      ns2
                           IN      CNAME   mary
           mary            IN      A       1.2.3.4

Information

Rating
Does not participate
Location
Ришон-ЛеЦион, Хамеркац, Израиль
Date of birth
Registered
Activity

Specialization

Server Administrator, DevOps
Lead