@romicohen
Системный Архитектор

При попытке использовать фасад Http — «cURL error 7: Failed to connect to xxx.test port 443: Connection refused» — что делать?

Всё это происходит в контексте Laradock (Docker Compose). Такой например код в routes/api.php:
Route::get('/gettest', function () {
    $response = Http::get('https://passport-api.test/api/protected');
    return $response->json();
});

выдает подобную ошибку.
Illuminate\Http\Client\ConnectionException: cURL error 7: Failed to connect to passport-api.test port 443: Connection refused (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://passport-api.test/api/protected in file /var/www/passport-api/laravel/vendor/laravel/framework/src/Illuminate/Http/Client/PendingRequest.php on line 785

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

Может кто сталкивался, подскажите а?
  • Вопрос задан
  • 668 просмотров
Пригласить эксперта
Ответы на вопрос 1
@McLotos
Если вдруг кто наткнётся на эту крайне продуктивную беседу (которая чуть выше), вот вам последовательность действий для нормального запуска сети docker-контейнеров как на серверах, так и локально:
  1. удаляете нах из конфигов nginx всё, что касается ssl
  2. создаете копию этого конфига, только меняете имя доменя на чего-то там .loc
  3. в docker-compose к контейнеру nginx добавляете env-параметры VIRTUAL_HOST, VIRTUAL_PORT, VIRTUAL_PROTO -- сами значения для них, понятное дело, должны лежать в вашем .env-файле (proto=http ну а порт, соответственно 80), коих, кстати, у вас должно быть минимум 2 -- один для боевого запуска и один для режима разработки
  4. в боевом env указываете старый (но уже без ssl) конфиг для nginx, а в тестовом тот, который .loc. Думаю это же не проблема подставить разные env в зависимости от окружения, да?
  5. конечно, докер создаст отдельную подсеть для проекта, что-то там my_best_super_project_default, но я всё-таки рекомендую прописать все её параметры вручную, но тут как бы choose yourself, bro! don't push me & don't f**k my brain!

После этих, в общем-то одноразовых плясок с бубном, порт для вашего чудо-мега-сайта будет выдаваться всегда случайно. Отставить панику! Сейчас починим!
Для начала создадим еще одну сеть, например proxy_network docker network create proxy_network
Добавляем в наш docker-compose вот такие строчки
networks:
  proxy_network :
    external: true

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

nginx
    image: nginx:alpine
    // тут что-то про диски и всё такое
    networks:
      - default
      - proxy_network

Идем в нашу любимую консольку и пишем команду, что-то типа
docker run docker run -d \
    -p 80:80 \
    -p 443:443 \
    -e DHPARAM_SKIP=true \
    --name nginx-proxy \
    --net proxy_network \
    -v /var/run/docker.sock:/tmp/docker.sock:ro \
    -v ./certs:/etc/nginx/certs:ro \
    -v ./vhost.d:/etc/nginx/vhost.d \
    -v letsencrypt-html:/usr/share/nginx/html \
    jwilder/nginx-proxy:alpine

почему alpine? да х.з., у меня всегда все контейнеры alpine, не суть, можете юзать свою любимую юбунту или ламповый деби, ни на что не влияет
После этого ваш сервер сможет поддерживать несколько проектов на 80 порту, а порты между самими проектами будут распределяться случайно. Магия вне Хоггвардс, блин!
Но мы-то хотим чтобы всё было защищено, мы хотим чтобы строка браузеров была зелёненькая, TLS и прочие плюшки. Тогда последний, финальный штрих, последняя команда, которая изменит вашу жизнь и она уже никогда не станет прежней! Назад пути нет! Поворачивай или умри!
docker run jrcs/letsencrypt-nginx-proxy-companion \
   --name letsencrypt-companion \
   -v /var/run/docker.sock:/var/run/docker.sock:ro \
   -v ./certs:/etc/nginx/certs \
   -v ./vhost.d:/etc/nginx/vhost.d \
   -v /etc/acme.sh:/etc/acme.sh\
   -v letsencrypt-html:/usr/share/nginx/html
   --volumes_from nginx-proxy

Эта фиговина постоянно мониторит (а точнее тырит у nginx-proxy список запущенных проектов и для каждого из них проверяет наличие ssl-сертификата. Если его нет или он устарел, она сама его обновит и будет за ним следить. На этом можно забыть про ssl на всегда и при этом не будет никаких плясок с бубном при локальном разворачивании проекта, где ssl по понятным причинам работать не сможет.

ну или можете забить на консольные команды, поправить свой docker-compose и nginx, как я выше описал и рядом с ним запустить вот такой docker-compose

БАМ! Готовый пример!
services:
  nginx-proxy:
    image: jwilder/nginx-proxy
    container_name: nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - ./certs:/etc/nginx/certs:ro
      - ./vhost.d:/etc/nginx/vhost.d
      - letsencrypt-html:/usr/share/nginx/html
  letsencrypt-companion:
    image: jrcs/letsencrypt-nginx-proxy-companion
    container_name: letsencrypt-companion
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./certs:/etc/nginx/certs
      - ./vhost.d:/etc/nginx/vhost.d
      - /etc/acme.sh:/etc/acme.sh
      - letsencrypt-html:/usr/share/nginx/html
    volumes_from:
      - nginx-proxy
volumes:
  letsencrypt-html:

Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы