🖧 Использование Curl для создания Telnet-соединения

Знание этих выводов может помочь вам устранить неполадки, если что-то пойдет не так.

Кстати, если у вас есть продвинутый вариант использования telnet, вы можете передать флаг –telnet-option в curl.

Зачем это нужно?

Возможно, вы работаете в контейнерной среде, где telnet или CLI-инструмент вашего сервиса недоступен, но у вас есть доступ к curl.

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

🐳 Почему процессы в контейнерах Docker не должны запускаться от имени Root

Например, у вас запущен кластер Kubernetes, и вы хотите быстро протестировать работу таких сервисов, как Redis или Memcached в вашем кластере.

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

Kubernetes позволяет настраивать зонды для проверки TCP-соединения на определенном порту, что позволяет убедиться в том, что на этом порту что-то работает:

spec:
  containers:
    - name: "redis"
      readinessProbe:
        tcpSocket:
          port: 6379

Но когда я запускаю что-то в первый раз, я также хочу убедиться, что оно «действительно» работает.

В этом «действительно» рабочем тесте и заключается использование telnet.

Если у вас установлен curl и настроены конфигурации Kubernetes, такие как настройка развертывания с сервисом для выставления redis в качестве действительного имени хоста, вы можете запускать:

curl -v telnet://redis:6379
*   Trying 172.30.0.3:6379...
* Connected to redis (172.30.0.3) port 6379 (#0)
   

Затем вы можете выполнить любую команду Redis, например, перечислить все ключи:

KEYS *
*3
...