Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (15)

Наибольший вклад в теги

Все теги (84)

Лучшие ответы пользователя

Все ответы (113)
  • Минимальные настройки безопасности Linux на VPS?

    Tyranron
    @Tyranron
    Ряд моментов Вы уже сделали, но я все равно их опишу для полноты списка.

    1. Создать отдельного пользователя и хороший пароль на sudo. Не использовать больше root напрямую. Совсем.

    2. SSH. Отключаем метод аутентификации по паролю. Если Вам не нужны другие методы, то их тоже можно отключить, оставив только publickey. Отключаем возможность аутентификации root'ом. Включаем использование только 2й версии SSH протокола.

    3. Устанавливаем Fail2Ban и настраиваем чтобы после нескольких неуспешных попыток подключения по SSH банило по IP на длительное время. Кол-во попыток и время бана можно тюнить в меру своей паранойи. У меня, например, банит на час после 2х неуспешных попыток.

    4. Iptables. Действуем по принципу "запрещено все, что не разрешено". Запрещаем по умолчанию весь INPUT и FORWARD трафик снаружи. Открываем на INPUT'е 22 порт. В дальнейшем открываем порты/forwarding по мере необходимости. Если у нас предполагаются сервисы на соседних серверах нужные только для внутренней коммуникации (Memcached, Redis, и т.д.), то открываем для них порты только для определенных IP. Просто так торчать наружу для всех они не должны.

    5. Настраиваем автоматические обновления apt-пакетов. Уровень security. То есть так, чтобы обновления безопасности накатывались автоматически, но при этом не выполнялись обновления со сменой мажорной версии (дабы обезопасить себя от "само сломалось").

    6. Устанавливаем ntpd. Серверное время должно быть точным. Также временную зону сервера лучше всего установить в UTC.

    7. TLS (не SSL) используем везде где можем. Через Let's Encrypt получаем бесплатные валидные сертификаты. В конфигах веб-серверов, mail-серверов, и других приложений торчащих наружу (в том числе и OpenVPN), запрещаем/убираем использование слабых шифров. Все ключи/параметры генерируем не менее 2048 бит. Самоподписные сертификаты подписываем с помощью SHA-256 (не SHA-1). Diffie-Hellman параметры (dh.pem) под каждый сервис лучше сгенерить отдельно. Проверяем TLS сервисов через Nmap. Минимальный grade должен быть A, не должно быть warning'ов.

    8. Правильный менеджмент пользователей/групп. Приложения/сервисы не должны запускаться под root'ом (разве что они действительно этого требуют и иначе никак). Для каждого сервиса создается свой пользователь.

    9. Если предполагается upload файлов через PHP (либо другие скриптовые языки), в директории, куда эти файлы загружаются (и которая доступна снаружи), должно быть жестко отключено любое выполнение скриптов/бинарников, что на уровне ОС (x права), что на уровне веб-сервера.

    Это была база.
    Дальше, в меру своей паранойи можно за'harden'ить сервер ещё следующими моментами:
    - SELinux, chroot
    - доступ к SSH только с определенных IP (нужно иметь 3-4 VPN-сервера под рукой)

    UPD И да, все это помнить/настраивать руками каждый раз может быть запарно. Используйте Ansible и автоматизируйте процесс (там родные и YAML, Jinja2 и Python).
    Ответ написан
  • Как отправить HTTP запрос методом POST на URL через PHP?

    Tyranron
    @Tyranron
    Действительно, за время, которое потратили на создание вопроса, Вы могли без проблем найти интересующую Вас информацию в любом поисковике.

    Но раз вопрос уже задан, то должен быть и ответ(ы).
    Собственно, @OnYourLips дал ссылку на хороший фреймворк, но если нет смысла тащить в проект/скрипт целый фреймворк ради одного запроса, к примеру, то логичнее воспользоваться упомянутым CURL. В Вашем случае сценарий использования CURL будет выглядеть примерно следующим образом:
    $myCurl = curl_init();
    curl_setopt_array($myCurl, array(
        CURLOPT_URL => 'http://target.site.com/form.php',
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_POST => true,
        CURLOPT_POSTFIELDS => http_build_query(array(/*здесь массив параметров запроса*/))
    ));
    $response = curl_exec($myCurl);
    curl_close($myCurl);
    
    echo "Ответ на Ваш запрос: ".$response;

    Если надо передать при этом ещё и файлы, или обратиться по https, или ещё чего Вам понадобится - добро пожаловать в документацию:
    http://php.net/manual/ru/book.curl.php
    Советую обратиться к документации в любом случае, дабы ознакомиться со всеми возможными нюансами, а также понять и выбрать то, что конкретно Вам потребуется для решения Вашей задачи.
    Ответ написан
  • Как правильно делать deploy с помощью docker registry?

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

    Давайте разберемся с инструментами и их предназначением, которые Вы используете:
    • Комманда docker - это консольный интерфейс (CLI) для работы с Docker
    • docker build создает по заданному Dockerfile образ контейнера
    • docker tag присваивает указанному образу указанный тег (опция -t для build делает то же самое)
    • docker pull скачивает указанный образ из удаленного регистра на текущую машину
    • docker push заливает указанный образ в удаленный регистр
    • docker run запускает новый контейнер из указанного образа
    • docker ps выводит список текущих "бегущих" контейнеров

    Команда docker не жонглирует файлами, она жонглирует образами и контейнерами, а они от нас абстрагированы Docker'ом, как что-то эфемерное. То есть выполняя комманду docker pull Вы не скачиваете образ в ту папку, где выполняете команду, и уж точно не скачиваете какие-либо файлы. Все что Вы делаете этой командой - это скачиваете образ в локальное хранилище Docker'а, дабы Docker daemon мог запустить контейнер на основании этого образа.

    Команда docker-compose - это уже совсем другая команда. Все что она делает - это читает указанный YAML-манифест и выполняет соответствующие команды Docker. Это всего лишь позволяет декларативно указывать желаемые сценарии при работе с Docker в удобном формате. Но ни команда docker, ни docker-compose, не предоставляют ничего для того, чтобы транспортировать/обновлять версии Ваших манифестов где-то там. Docker, опять таки, жонглирует образами и контейнерами, не более.

    У Вас в манифесте указана директива build:. Таким образом docker-compose пытается сначала собрать контейнер, вместо того, чтобы просто запустить его из образа.

    Касательно совета docker-compose.yml под каждый env, все правильно советовали. Именно так это и задумывалось. Вы в манифесте указываете отнюдь не разные окружения (development, production), а набор контейнеров, которые должны бежать в одной связке одной логической единицей (концепция POD'ов). Ничего не запрещает делать и так, как сделали Вы, но это сродни использованию дуршлага в роли миски для еды: сегодня Вы нормально из него наворачиваете пельмени, а завтра супчик в нем уже куда-то не туда утекает.

    Воркфлоу в Вашем случае можно организовать следующим образом:
    1. На dev-машине у Вас один docker-compose.yml, согласно которому контейнер перед запуском собирается из сорцов.
    2. Когда у Вас готова новая версия приложения, Вы его собираете через docker build, присваиваете ему номер версии через docker tag и отправляете в удаленный регистр образов через docker push.
    3. На prod-машине у Вас отдельный docker-compose.ymlв котором указано запускать конкретную версию образа (и никаких build). Новая версия приложения - меняем тег образа в манифесте и перезапускаем контейнеры. При выполнении docker-compose образ автоматически скачается перед запуском, если его нет локально. Если же Вы обновили образ конкретной версии, которая уже была скачана ранее, то да, нужно выполнить docker pull перед стартом, дабы скачать новый образ.


    Дополнительный совет:
    Сборку образа и его заливку в удаленный регистр часто удобно автоматизировать с помощь Makefile'ов.
    Ответ написан
  • Есть ли разница между горутинами и await в C#?

    Tyranron
    @Tyranron
    Несмотря на то, что эти инструменты созданы для решения одних и тех же проблем, делают они это по-разному, как под капотом, так и в плане предлагаемых абстракций. Потому нельзя сказать что async/await в C# - это "просто обертка над горутинами".

    Горутины в Go - это концепция stackful coroutines (под капотом) + CSP (в абстракциях). Каждый раз, когда мы создаём горутину, под неё выделяется отдельный стек вызовов для её собственных нужд. При этом, когда происходит паника, то stack unwinding (размотка стека вызовов) происходит только в пределах этой горутины и не покидает границ её стека. Стек горутины полностью отвязан от стека её создания/вызова, потому горутина не может возвращать результат. Любое общение между горутинами выполняется либо посредством каналов, либо какой-то общей памяти.

    async/await в C# (то есть, Task'и) - это концепция stackless coroutines (под капотом) + futures (в абстракциях). Код с async/await'ами компилятор превращает в определенную стэйт-машину с yield point'ами. У них нет отдельного стека, они выполняются в том же стеке что и вызывающий их код. Соотвественно, есть возможность словить exception'ы (аналог panic'и) возникающие внутри асинхронного Task'а прямо в запускающем его коде. Так как выполнение идёт на том же стеке - Task нормально может возвращать результат и мы его можем считать в вызывающем коде без дополнительных примитивов/инструментов.

    При этом, если мы запустим Go с GOMAXPROCS=1, то мы получим однопоточный асинхронный код в Go (по умолчанию он многопоточный). Также и в C# мы можем выполнять Task'и как на одном потоке, так и на thread pool, получая аналогичные Go гарантии рантайма.

    С точки зрения абстракций/использования - это уже вкусовщина. Кому как больше нравится. У futures лучше дизайн в плане composability (их эргономичнее join'ить и select'ить), но они вынуждают писать везде async и await. У горутин надо постоянно городить чехарду с синхронизацией (попробуйте сделать аналог await для произвольной горутины), но если эту чехарду прятать под капот (как обычно и делают), то код вообще выглядит полностью синхронным и программисты радуются.
    Ответ написан
  • Go + Nginx: научите использовать правильно

    Tyranron
    @Tyranron
    как лучше обращаться к Go, через Proxy или FastCGI?

    И так и так хорошо. Я все же предпочитаю вариант проксировать запросы на Go.

    Не могу проверить вообще, так как на рабочей машине Windows.

    Это не проблема, поставьте виртуалку и вперед. В конце-концов: личный опыт лучше любых объяснений.

    И ещё очень странный вопрос: нужно-ли при таком подходе компилировать Go? Просто где-то видел пример кода, когда обращаются к исходному файлу с расширением .go.

    Компилировать нужно, особенно в случае большого приложения.
    Да, можно сделать:
    go run file.go
    Но, во-первых, код все равно компилируется в бинарник и выполняется при таком подходе, просто это происходит в папке с временными файлами и как бы скрыто от Вас.
    Во-вторых, этот подход не катит, если в папке с проектом больше файлов нежели file.go (имеется в виду на уровне package main).
    В-третьих, это обязует Вас иметь установленный Go соответственной версии на production серверах, когда обычный бинарник этого не требует.
    В-четвертых, а как быть в таком случае с демонизацией и zero downtime reloads? Да, можно, но неудобно, учитывая что каждый раз нужно будет перекомпиливать.
    Лучше скомпилировать один раз и не заморачиваться.
    Команда go run больше подходит для небольших файлов аля скрипт для выполнения одноразовой работы и тому подобное.

    Прошу не кидать камнями, я только учусь правильному написанию веб-сайтов на Go.

    Учиться - всегда полезно, никто камнями кидать не будет.
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (1)