docker容器无法访问宿主机端口的解决

最近在工作时遇到一个问题,docker容器无法访问宿主机的redis,telent6379端口不通。

经排查发现,该服务器启用了防火墙,防火墙把6379的端口的访问授权给docker0网卡访问即可。

操作如下:

firewall-cmd --permanent --zone=trusted --change-interface=docker0

firewall-cmd --reload

补充知识:docker 启动mysql 容器出错Ports are not available: listen tcp 0.0.0.0:3306

错误截图如下

该错误是由于本地3306端口被占用,很可能是本地已经安装了mysql,mysql服务已经启动导致的

解决办法一:打开服务,找到mysql服务,将其停止,或者更换端口

然后再执行以下命令

docker run --name MYSQL -e MYSQL_ROOT_PASSWORD=123456 -p 3306:3306 -itd mysql:latest /bin/bash

如图,则启动成功

解决办法二:更换端口映射

docker run --name MYSQL -e MYSQL_ROOT_PASSWORD=123456 -p 3309:3306 -itd mysql:latest /bin/bash

说明:

-p 3309:3306:-p 宿主机端口:容器端口,即将宿主机3309端口映射到容器的3306端口,在宿主机登录容器数据库的时候,使用宿主机端口,如3309

以上这篇docker容器无法访问宿主机端口的解决就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持我们。

(0)

相关推荐

  • Docker容器网络端口配置过程详解

    暴露网络端口 实际上,Docker中涉及暴露网络端口的参数有两个,分别是-p和-P.下面分别来介绍. -P 使用-P,Docker会在宿主机上随机为应用分配一个未被使用的端口,并将其映射到容器开放的端口,以Nginx 为例,如下: 可以看到,Docker为应用分配了一个随机端口32768,使用该端口即可访问容器中的 nginx(http://lcalhost:32768). -p -p参数则有几种不同的用法: hostPort:containerPort 这种用法是将宿主机端口和容器端口绑定起来

  • Docker容器访问宿主机网络的方法

    最近部署一套系统,使用nginx作反向代理,其中nginx是使用docker方式运行: $ docker run -d --name nginx $PWD:/etc/nginx -p 80:80 -p 443:443 nginx:1.15 需要代理的API服务运行在宿主机的 1234 端口, nginx.conf 相关配置如下: server { ... location /api { proxy_pass http://localhost:1234 } ... } 结果访问的时候发现老是报 5

  • 在docker容器中调用和执行宿主机的docker操作

    首先这个帖子,献给docker新手.当然如果你是一个老手,文中分割线后的操作方法也是一种思路. 首先说一下,如何在docker中执行宿主机的docker操作,我们管它叫docker in docker. 至于为什么要在docker中操作宿主机的docker,优点不言而喻,你既可以将你的具体需求容器化部署,又不用直接在宿主机上安装(假设我们没有办法在docker中操作宿主机的docker,那么我们只能将这样的软件程序直接安装到宿主机上,这样显然是不利于管理和维护的). 实现这种需求,其实非常简单,

  • Docker 给运行中的容器设置端口映射的方法

    一.概念 Docker 端口映射即映射容器内应用的服务端口到本机宿主机器. 二.实现 当容器中运行一些网络应用,要让外部访问这些应用时,可以通过 -P 或 -p 参数两种方式来指定端口映射. 1. 随机映射 使用 -P 参数时,Docker 会随机映射一个端口到内部容器开放的网络端口,如下开启一个 nginx 服务: $ docker run -d -P nginx e93349d539119dc48dc841e117f6388d6afa6a6065b75a5b4aedaf5fb2a051fc

  • docker容器无法访问宿主机端口的解决

    最近在工作时遇到一个问题,docker容器无法访问宿主机的redis,telent6379端口不通. 经排查发现,该服务器启用了防火墙,防火墙把6379的端口的访问授权给docker0网卡访问即可. 操作如下: firewall-cmd --permanent --zone=trusted --change-interface=docker0 firewall-cmd --reload 补充知识:docker 启动mysql 容器出错Ports are not available: listen

  • docker容器间跨宿主机通信-基于overlay的实现方法

    overlay网络解析 内置跨主机的网络通信一直是Docker备受期待的功能,在1.9版本之前,社区中就已经有许多第三方的工具或方法尝试解决这个问题,例如Macvlan.Pipework.Flannel.Weave等. 虽然这些方案在实现细节上存在很多差异,但其思路无非分为两种: 二层VLAN网络和Overlay网络 简单来说,二层VLAN网络解决跨主机通信的思路是把原先的网络架构改造为互通的大二层网络,通过特定网络设备直接路由,实现容器点到点的之间通信.这种方案在传输效率上比Overlay网络

  • docker内服务访问宿主机服务的实现

    目录 1. 场景 2. 解决 3. 总结 4. 参考 1. 场景 使用windows, wsl2 进行日常开发测试工作. 但是wsl2经常会遇到网络问题.比如今天在测试一个项目,核心功能是将postgres 的数据使用开源组件synch 同步到clickhouse 这个工作. 测试所需组件 postgres kafka zookeeper redis synch容器 最开始测试时,选择的方案是, 将上述五个服务使用 docker-compose 进行编排, network_modules使用ho

  • 关于Docker容器内部无法解析域名问题的解决

    发现问题 最近工作中部署一个项目,在项目内部需要访问外网.给某云上传文件,但是一直报unknown host,无法解析域名,然后找了好久原因,下面废话不多说,来一起看看详细的解决方法: 解决方法 Linux系统默认没有打开IP转发功能,要确认IP转发功能的状态,可以查看/proc文件系统,使用下面命令: cat /proc/sys/net/ipv4/ip_forward 0 如果上述文件中的值为0,说明禁止进行IP转发:如果是1,则说明IP转发功能已经打开,要想打开IP转发功能,可以直接修改上述

  • 详解如何解决docker容器无法通过IP访问宿主机问题

    问题起源 在使用 docker 的过程中我不幸需要在 docker 容器中访问宿主机的 80 端口, 而这个 80 端口是另外一个容器 8080 端口映射出去的. 当我在容器里通过 docker 的网桥 172.17.0.1 访问宿主机时, 居然发现: curl: (7) Failed to connect to 172.17.0.1 port 80: No route to host 查找问题原因 可以确定的是容器与宿主机是有网络连接的, 因为可以在容器内部通过 172.17.0.1 Ping

  • 在Docker容器中部署静态网页的方法教程

    前言 一般我们在访问容器时需要通过容器的端口来访问,那如何设置容器的端口映射呢? 我们通过以下命令来设置: docker run -p ip:hostPort:containerPort [--name] [-i] [-t] 镜像名 [COMMAND][ARG...] ip:表示宿主机ip hostPort:宿主机端口号 containerPort:容器端口号 设置的方式有以下几种: containerPort,指定容器端口号,宿主机端口随机生成 [root@localhost ~]# dock

  • docker容器中无法获取宿主机hostname的解决方案

    在nodejs环境中测试通过,其它语言同理,只需要使用获取环境变量的方法即可. 思路: docker容器和宿主机环境是隔离的,但是可以在启动docker容器时将宿主机的主机名以环境变量的形式传入,代码在容器中获取该值即可. 操作: docker run -d -p 3000:3000 --name myTest -e HOST_Q=$(hostname) mytest:v1 # 使用-e 参数传入环境变量,值为主机名 如果使用yml文件启动: version: '3' services: mys

  • 详解Docker 容器互联方法

    Docker容器都是独立的,互相隔离的环境.然而,它们通常只有互相通信时才能发挥作用. 虽然有许多方法可以连接容器们,可是我将并不会试着去将其全部讨论在内.但是在这一系列的方法中,我们将看看那些常用的做法. 虽然看起来是很浅显,但是这对于与Docker成天打交道的朋友来说,理解这些技术及底层的设计理念就显得非常地重要了. 理解这些主题将会: 帮助开发和运维人员探索广泛的容器部署的选择. 让开发和运维人员更自信的着手于微服务microservice架构设计. 让开发和运维人员可以较好的编排更复杂的

随机推荐