Георг Гаал

Что интересно что при таком конфиге.
Неработало если использовался Shell runner.
Заработало когда запустил в docker

it_unit_test:
  stage: test
  image: "$build_img"
  dependencies:
    - build
  services:
    - name: "$pgsql_img"
      alias: db
  script:
    - docker ps     || echo $?
    - ping -c 1 db  || echo $?
    - mvn test -P intTests
  tags:
    - docker-only

Решилось
Вывод вот такой.

$ ping -c 1 db  || echo $?
/bin/bash: line 93: docker: command not found
PING db (XXXXXX) 56(84) bytes of data.
64 bytes from XXXXX (XXXXX): icmp_seq=1 ttl=64 time=0.192 ms

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

api = MainApi()
api.verifyUser(email, password)

либо сделайте метод verifyUser методом класса

class MainApi(object):
    server = 'http://127.0.0.1:8000'

    @classmethod
    def verifyUser(cls, email, password):
        #тут параметры и тд
        r = requests.get(cls.server + '/api/login/verifyuser/', params=req_params)
        return r.json()

Привет, тебе нужно изменить файл /etc/fstab, добавить строку вида
/dev/sda1 /var/www/domain.ru ext4 errors=remount-ro 0 0
Где /dev/sda1 -н звание нового диска
ext4 - тип файловой системы, после того как изменил, напиши команду mount -a чтобы применить

Обычно systemd-хейтеры находятся в возрасте 14-18 лет и настоящих Unix™ в глаза не видели.
1. systemd — лучшее что случалось с init-системой дистрибутивов GNU/Linux за последние 18 лет(именно столько я работаю с *nix-like и именно за этот отрезок времени я могу отвечать)
2. systemd — прямой аналог launchd и smf которые как раз в сертифицированных Unix™ живут.

А все эти визги про «не юниксвейно» раздаются от тех, кто только с мамкиных компов на лоре читал, что так надо попискивать.

Цитата взята отсюда:
https://habr.com/ru/company/southbridge/blog/31570...

Я согласен с автором на 100%.

Начну с того, что если вы таки активный разработчик и не очень можете понять этот принцип, возможно он вам просто не нужен. И это не значит что вы плохой разработчик, просто не пересекались с таким видом проблем.
Что касается serverless, название больше отражает не факт отсутствия сервера и работы с ним как таковым, а скорее еще меньше возни с настройкой и поддержкой серверного окружения (даже меньше чем с докером после того как все настроено и поднято). Те это следующие шаг после условных микросервисов.
Его часто удобнее называть функция как услуга, так как де факто часто реализуется запуск именно функции по запросу.
Если кратко описать для чего это нужно, то представим себе что у нас есть микросервис у которого затраты на содержания его постоянного аптайма как то слишком велики относительно времени работы/потребления ресурсов в живую. Да и в целом сервис выходит как то слишком микро даже для микросервиса.
Вот тут мы и придумываем такую штуку, которая будет ОЧЕНЬ быстро(относительно старта минимальной виртуалки/образа и чего другого) запускаться, быстро делает свою маленькую работу и выключается.
Из ключевых особенностей отмечу что функции должно быть в целом пофиг на своего состояние, она не знает изначально о предыдущем запуске и тп(те быть stateless). Все что нужно приходит в запросе.
Ври значит если у вас есть задача, которая удовлетворяет этим условиям, можно использовать этот удобный сервис и для масштабируемости, и для экономии и для кучи других фич.
Примеры:
ресайз изображений.
Генератор статистических сайтов(через админку производим обновление статистических файлов, это бывает не часто).
Чат боты
Разные спец информеры с определенной логикой.
И тд и тп, что хорошо ложится в определенную относительно простую функцию с простым входом данных(или без) и простым результатом работы.
В целом это решение не панацея, более того нужно четко понимать насколько выгодно/невыгодно переделывать на серверлесс платформы свою функцию, ведь мы точно жертвуем той же производительностью(помним что сервис не висит и не ждет нас постоянно, а пусть и очень быстро, но запускается), понижается прозрачность исполнения и усложняется отладка и прочее.
Но в любом случае, достаточно часто плюсы перебивают минусы, популярность у этого принципа есть. люди активно пользуются, так что много шишок уже набито, в целом зрелая штука.
А и да, насчет конкретного вашего вопроса.
PHP AWS Lambda нативно не поддерживает, все через костыли, впрочем с почти вменяемой производительностью.
И так как все таки AWS Lambda все же ближе к самому популярному нынче принципу serverless - функция как сервис, я не уверен что это правильная идея будет запускать атм Ларавел.
Те мы имеем минусы: отсутствие нативной поддержки PHP и такие заточенность под что-то простое, в итоге .. ну не знаю.
Я думаю плюшки serverless в виде нет мороки с настройкой сервера/облака можно решить многими другими сервисами. Впрочем может быть это будет не так выгодно в вашем случае, нужно исходить и рассчитывать по вашему сценарию работы вашего приложения. А потом решать, что лучше подходит.

Проектирование это процесс в результате которого получается проект системы. Уровень проектирования не важен, т к верхние уровни декомпозируются в нижние. Архитектура системы это принципиальные решения о ее устройстве. Например SPA или SSR, микросервисы, монолит или модульная система. Причем в процессе проектирования может принято решение о смене архитектуры. Что кстати и следует из определения проектирования. Короче архитектура системы это часть проекта, но выбор архитектуры определят проект. И как итог архитектура это часть высокоуровнего проектирования.

Политики где? Отдельная маршрутизация - ну по крайней мере на микротике - не нужна. Микротик сам разберется куда что направить. Но естественно нужны правила файрволла, пропускающие трафик после его расшифровки.
Именно политики увязывают вирутальные подсети и туннель.
То есть если на пальцах, что происходит после того, как соединение есть.
1. Входящий пакет.
Микротик получил ESP-пакет. Если правила файрволла его пропустили (цепочки input/output, а не forward!), то микротик смотрит ассоциации безопасности (SA) - есть ли ассоциация с данным ID? Если есть, то пакет расшифровывается и повторно проходит файрволл - на этот раз цепочку forward - и уходит в нужный интерфейс.
2. Исходящий пакет
Микротик получил пакет из внутренней сети. Если правила цепочки forward его пропустили, то он смотрит политики безопасности (SP) - нужно ли этот пакет шифровать. Если нужно, то из политики берутся адреса начала и конца туннеля, по ним ищется SA, из SA берется ключ, пакет шифруется и снова проходит файрволл - в шифрованном виде. Если его пропустили - он пошел.
Нету тут нигде маршрутизации, тут ESP вместо нее. Зухель точно расшифровывает пакеты от микротика? Если используете SHA256 - откажитесь, у микротика какая-то своя собственная реализация, совместимая только с микротиком, поставьте SHA1.