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

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

1. ubuntu装置docker

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

# 卸载旧版本apt-get remove docker docker-engine docker.io containerd runc# 装置依赖apt updateapt-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

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

2.docker-compose装置

 # 下载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

3.docker-compose

在我应用的我的项目中应用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

学习之路无止境！！！