关于docker:dockercompose一键部署django

2次阅读

共计 2492 个字符，预计需要花费 7 分钟才能阅读完成。

因为在这段时间里，总是须要为我的项目更换新的服务器，每次手动配置 django 环境曾经是纯熟得不要不要了。只管曾经达到一个相当纯熟的状态，整个我的项目在全新的服务器中部署下来还是须要一两个小时，而且都是重复性的劳动，为了更好地迁徙我的项目，我抉择尝试用 docker 和docker-compose来创立和启动容器，实现尽可能不便地一键式部署。

在理论的生产中，一个我的项目须要定义数量总多的 docker 容器，并且容器之间有着盘根错节的依赖关系，手动创立和配置简单的容器关系，效率会很低下。docker-compose能够定义容器集群编排，能够在不同的服务器上一键式复用配置。

ubuntu 中自带了低版本的 docker，须要先卸载旧版本，再装置最新的版本

# 卸载旧版本
apt-get remove docker docker-engine docker.io containerd runc

# 装置依赖
apt update
apt-get install ca-certificates curl gnupg lsb-release

# 装置 GPG 证书
curl -fsSL http://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo apt-key add -

# 写入软件源
add-apt-repository "deb [arch=amd64] http://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable"

# 装置新版本
apt-get install docker-ce docker-ce-cli containerd.io

在装置后须要对 docker 进行换源，应用国内镜像源进步下载速度

vim /etc/docker/daemon.json # 未配置过期，该文件不存在，往其中退出上面内容

# 退出内容
{"registry-mirrors": ["https://y0qd3iq.mirror.aliyuncs.com"]
}

# 重启 docker，让其失效
systemctl restart docker

最初能够通过上面命令判断是否批改胜利

docker info | grep -i Mirrors -A 1

输入后果里有退出的镜像源，即批改胜利

 # 下载 docker-compose
 curl -L https://github.com/docker/compose/releases/download/1.17.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
 
 # 减少执行权限
 sudo chmod +x /usr/local/bin/docker-compose
 
 # 查看是否装置胜利
 docker-compose --version

在我应用的我的项目中应用django+uwsgi+nginx+mysql，在我的项目中编排了 3 个容器：

django+uwsgi 容器：python 后端框架和解决动静申请
mysql 容器：数据库框架
nginx 容器：解决动态资源申请

其实整个 docker-compose 最重要的就是 docker-compose.yml 外围编排文件，我的编排文件是在这篇大神文章的根底上批改的，你能够依据本人我的项目里须要的货色数量不同来批改你的编排文件，无论是减少容器还是缩小容器。

 # 进入 docker-compose.yml 所在文件夹，输出以下命令构建镜像
 sudo docker-compose build
 
 # 查看已生成的镜像
 sudo docker images
 
 # 启动容器组服务，这里启动后会始终运行，不能敞开，这里能够举荐 nohup 或者 tmux 让命令始终运行
 sudo docker-compose up
 
 # 查看运行中的容器
 sudo docker ps

总的来说，在实现你的编排文件和各个容器所须要的配置文件后，应用 docker-compose 构建镜像和启动容器组服务，就能够省去一系列的环境配置，独自配置环境还能够呈现各种坑，然而在 docker 中却是不存在，一切都是顺通无阻。

当然更重要的是排错，在写配置文件是会呈现一系列的问题，所以最重要的是排错，排错要好好的看日志文件中的报错，上面列举了一些我遇上的谬误

uwsgi 启动谬误并不会进行过程，然而此时如果你通过端口去拜访的话会呈现的谬误 502 Bad Gateway，这个时候须要去日志中查看失败的信息，日志文件在你的配置文件uwsgi.ini 中项 daemonize 就是 uwsgi 的谬误日志门路，而绝大多数的谬误都是因为该配置文件内容的谬误导致

端口占用

probably another instance of uWSGI is running on the same address (0.0.0.0:8000).
bind(): Address already in use [core/socket.c line 769]

谬误起因是重复使用 uwsgi uwsgi.ini 命令，8000 端口曾经被占用，应用命令 pkill -f uwsgi -9 敞开所有 uwsgi 的过程，在 bash 中能够通过应用命令 ps -ef 查看所有过程。

module 设置谬误

--- no python application found, check your startup logs for errors ---

次要是因为配置文件 uwsgi.ini 中的 module 设置的问题，module=project_name.wsgi:application这里的 project_name 肯定要和本人我的项目根目录下蕴含 setting.py 的文件夹名字雷同，原配置是绝对路径的也须要改为module=project_name.wsgi:application

整篇文章是在大江狗的文章的配置根底上批改实现 Docker 部署 Django 由浅入深系列(下): 八步部署 Django+Uwsgi+Nginx+MySQL+Redis

学习之路无止境！！！

正文完