码迷,mamicode.com
首页 > 其他好文 > 详细

部署基于Gitlab+Docker+Rancher+Harbor的前端项目这一篇就够了

时间:2020-02-26 23:04:44      阅读:75      评论:0      收藏:0      [点我收藏+]

标签:mon   简单   pull   迭代   view   快速   system   cad   meta   

部署基于Gitlab+Docker+Rancher+Harbor的前端项目这一篇就够了

技术图片
momenta 中台开发工程师
技术图片

就目前的形势看,一家公司的运维体系不承载在 Docker+Harbor(或 Pouch 等同类平台)之上都不好意思说自己的互联网公司。当然这些技术也不适用于全部公司,技术在迭代,平台也一样,把我使用的工具和大家分享下,一起成长(文章中扩展可按需Google)。

Docker

docker的架构图如下:

技术图片

从图中可以看出几个组成部分

  • docker client: 即 docker 命令行工具
  • docker host: 宿主机,docker daemon 的运行环境服务器
  • docker daemondocker 的守护进程,docker client 通过命令行与 docker daemon 交互
  • container: 最小型的一个操作系统环境,可以对各种服务以及应用容器化
  • image: 镜像,可以理解为一个容器的模板配置,通过一个镜像可以启动多个容器
  • registry: 镜像仓库,存储大量镜像,可以从镜像仓库拉取和推送镜像

我在刚接触到Docker的时候,产生了一种错觉--这不就是个性能不错的虚拟机吗?显然他能做的远比虚拟机多得多。具体表现在 Docker 不是在宿主机上虚拟出一套硬件后再虚拟出一个操作系统,而是让 Docker 容器里面的进程直接运行在宿主机上(Docker 会做文件、网络等的隔离),这样一来 Docker 会 “体积更轻、跑的更快、同宿主机下可创建的个数更多”(类似于一个一个的沙箱,互相不暴露接口,互相不影响)。

Docker 中有三个核心概念:Image、Container、Repository。

  • Image: 和 windows 的那种 iso 镜像相比,Docker 中的镜像是分层的,可复用的,而非简单的一堆文件迭在一起(类似于一个压缩包的源码和一个 git 仓库的区别)。
  • Container: 容器的存在离不开镜像的支持,他是镜像运行时的一个载体(类似于实例和类的关系)。依托 Docker 的虚拟化技术,给容器创建了独立的端口、进程、文件等“空间”,Container 就是一个与宿机隔离 “沙箱”。沙箱可在宿主机之间可以进行 port、volumes、network 等的通信。
  • Repository: Docker 的仓库和 git 的仓库比较相似,拥有仓库名、tag。在本地构建完镜像之后,即可通过仓库进行镜像的分发。常用的 Docker hub 有  、  等。

底层原理

docker 底层使用了一些 linux 内核的特性,大概有 namespacecgroups 和 ufs

namespace

docker 使用 linux namespace 构建隔离的环境,它由以下 namespace 组成

  • pid: 隔离进程
  • net: 隔离网络
  • ipc: 隔离 IPC
  • mnt: 隔离文件系统挂载
  • uts: 隔离hostname
  • user: 隔离uid/gid

control groups

也叫 cgroups,限制资源配额,比如某个容器只能使用 100M 内存

Union file systems

UnionFS 是一种分层、轻量级并且高性能的文件系统,支持对文件系统的修改作为一次提交来一层层的叠加。docker 的镜像与容器就是分层存储,可用的存储引擎有 aufsoverlay 等。

镜像

镜像是一份用来创造容器的配置文件,而容器可以视作最小型的一个操作系统(类似于容器由镜像解压而来)。

docker 的镜像和容器都使用了 unionFS 做分层存储,镜像作为只读层是共享的,而容器在镜像之上附加了一层可写层,最大程度地减少了空间的浪费,详见下图

技术图片

镜像仓库与拉取

我们可以在官方镜像仓库拉取镜像,也可以自己构造镜像

# 加入拉取一个 node:alpine 的镜像
$ docker pull node:alpine

# 查看镜像信息
$ docker inspect node:alpine

# 列出所有镜像
$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
node                alpine              f20a6d8b6721        13 days ago         105MB
mongo               latest              965553e202a4        2 weeks ago         363MB
centos              latest              9f38484d220f        8 months ago 

镜像的构造与发布

镜像仓库里找不到全部的镜像,这时我们需要为自己的业务去构建镜像了。

-t 指定标签

# -t node-base:10: 镜像以及版本号
# .: 指当前路径
$ docker build -t node-base:10 ./
#使用docker push将镜像推送到镜像仓库
$ docker push node-base:10

Dockerfile

在使用docker部署自己应用时,往往需要自己构建镜像。docker使用Dockerfile作为配置文件构建镜像,简单看一个node应用构建的dockerfile

FROM node:alpine

ADD package.json package-lock.json /code/
WORKDIR /code

RUN npm install --production
#.为当前文件目录 /code为镜像内的目录
ADD . /code

CMD npm start 

FROM

基于一个旧的镜像,格式如下

FROM <image> [AS <name>] 
# 在多阶段构建时会用到 
FROM <image>[:<tag>] [AS <name>]

ADD

把目录,或者 url 地址文件加入到镜像的文件系统中

ADD [--chown=<user>:<group>] <src>... <dest>

RUN

执行命令,由于 ufs 的文件系统,它会在当前镜像的顶层新增一层

RUN <command>

CMD

指定容器如何启动

一个 Dockerfile 中只允许有一个 CMD

# exec form, this is the preferred form 
CMD ["executable","param1","param2"] 
# as default parameters to ENTRYPOINT 
CMD ["param1","param2"] 
# shell form 
CMD command param1 param2

容器

镜像与容器的关系,类似于代码与进程的关系。

  • docker run 创建容器
  • docker stop 停止容器
  • docker rm 删除容器


创建容器

基于 nginx 镜像创建一个最简单的容器:启动一个最简单的 http 服务

使用 docker run 来启动容器,docker ps 查看容器启动状态

$ docker run -d --name nginx -p 8888:80 nginx:alpine  
$ docker ps -l 
CONTAINER ID        IMAGE                COMMAND                  CREATED             STATUS              PORTS                    NAMES 
404e88f0d90c        nginx:alpine         "nginx -g ‘daemon of…" 4 minutes ago       Up 4 minutes        0.0.0.0:8888->80/tcp     nginx 
CONTAINER ID        IMAGE                COMMAND                  CREATED             STATUS              PORTS                    NAMES

其中:

  • -d: 启动一个 daemon 进程
  • --name: 为容器指定名称
  • -p host-port:container-port: 宿主机与容器端口映射,方便容器对外提供服务
  • nginx:alpine: 基于该镜像创建容器

此时在宿主机使用 curl 测试容器提供的服务是否正常

curl localhost:8888
会在下方打印出html代码

使用docker exec -it container-name命令可以进入容器的环境中


容器管理

docker ps 列出所有容器

$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

404e88f0d90c        nginx:alpine         "nginx -g ‘daemon of…" 4 minutes ago       Up 4 minutes        0.0.0.0:8888->80/tcp     nginx 
498e7d74fb4f        nginx:alpine         "nginx -g ‘daemon of…" 7 minutes ago       Up 7 minutes        80/tcp                   lucid_mirzakhani 2ce
10556dc8f        redis:4.0.6-alpine   "docker-entrypoint.s…" 2 months ago        Up 2 months         0.0.0.0:6379->6379/tcp   apolloserverstarter_redis_1

docker port 查看容器端口映射

$ docker port nginx 80/tcp -> 0.0.0.0:8888

docker stats 查看容器资源占用

$ docker stats nginx CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS 
404e88f0d90c        nginx               0.00%               1.395MiB / 1.796GiB   0.08%               632B / 1.27kB       0B / 0B             2

Harbor

它的目标是帮助用户迅速搭建一个企业级的 Docker registry 服务。它以 Docker 公司开源的 registry 为基础,提供了管理UI,基于角色的访问控制(Role Based Access Control),AD/LDAP集成、以及审计日志(Auditlogging) 等企业用户需求的功能,同时还原生支持中文。Harbor 的每个组件都是以 Docker 容器的形式构建的,使用 Docker Compose 来对它进行部署。


Rancher

rancher 容器管理平台 在生产环境中轻松快捷的部署和管理容器 管理K8s 内置CI/CD 快速搭建 导入和纳管 集中式身份。

准确的说,Rancher是一套容器管理打包方案,支持三种编排引擎:Kubernetes,Swarm,还有Rancher自己开发的Cattle(最近好像换成了Mesos)。从功能的完整性和易用性来看,Rancher甚至可以算得上一个商业软件了,部署极其简单,这也是我们选择它作为入门级容器管理平台的原因。以下是Rancher的组件图:

技术图片

虽然Rancher非常的易用,但是rancher也不都是优点,随着后端机器和项目数量的增加,它的一些问题也更易暴露,UI卡顿,发布速度越来越慢,1.3之后甚至经常出现服务的预期状态(容器数量,版本)无法被保证,卡在发布中或者完成中状态。团队后续可能会考虑使用kubernetes。

基于GitLab的CI/CD

个人理解就是把代码测试、打包、发布等工作交给一些工具来自动完成。这样可以提高效率,减少失误,开发人员只需要关心开发和提交代码到git就可以了。

使用工具如gitlab-CI,这种方式的原理就是为项目在自己的服务器安装上注册gitlab-runner,注册会有一个token,服务器上运行gitlab-runner后,runner会轮询的发送带tokenhttp请求给gitlab,如果gitlab有任务了,(一般是git push),那么会把任务信息返回给runner,然后runner就开始调用注册时选的Executor(我是用的shell)来执行项目根目录下的配置文件.gitlab-ci.yml,执行后把结果反馈给gitlab
详细的工作原理请参考:

当谈到 GitLab CI 的时候,我们该聊些什么(上篇)?www.upyun.com

对GitLab-CI,GitLab-Runner等概念不清楚,参考:

GitLab-CI与GitLab-Runner - CNundefined - 博客园?www.cnblogs.com技术图片

开发环境要求

1、gitlab远程仓库

2、本地配置文件gitLab-ci.yml

stages:
  - test
  - build
  - push
  - deploy

variables:
 image:.......
.deploy_test_refs: &deploy_test_refs
  - development
  - test

.deploy_production_refs: &deploy_production_refs
  - master

# all_deploy_refs = deploy_test_refs + deploy_production_refs, but YAML cannot concat arrays
.all_deploy_refs: &all_deploy_refs
  - development
  - test
  - master

3、服务器上配置nginx、gitlab-runner(注册runner,修改runner的权限)

sudo chown -R gitlab-runner:gitlab-runner /home/gitlab-runner
sudo chmod -R 777 /home/gitlab-runner

开启runner

 gitlab-runner run

4、本地配置好node、git

配置成功展示界面:

技术图片

参考文章:

前端项目基于GitLab-CI的持续集成/持续部署(CI/CD) - 掘金?juejin.im

使用Docker+Rancher(结合gitlab)+Harbor的具体流程

环境准备

1、macpro+多出来的服务器(没有也可以)

2、docker 版本:18 (最新也成)

3、docker-compose:1.24 (最新也成)

4、Harbor:1.1.2(最新也行)

安装docker

brew cask install docker

打开docker客户端之后再item中输入

docker login 域名

然后就可以在客户端中输入用户名与密码,由于作者使用公司的内网(不涉及业务内容),因此需要事先配置好推到harbor内的权限

技术图片

处理过权限问题,之后的阶段就可以进入相应的文件夹进行手动的配置,前提是要先写好一个类似于build.sh的文件,内部配置好各种命令,build文件中的内容

function build() {
  echo "------------------------------ BUILD ------------------------------"

  (cd frontend && env COMMIT_ID=${COMMIT_ID} BUILD_TIME=${TIMESTAMP2} $(cat .env.${DEPLOY}) yarn build)

  rm -rf docker/frontend
  cp -r frontend/build docker/frontend

  # local IMAGES=`docker images -q -f ‘dangling=true‘`
  # [ "$IMAGES" != ‘‘ ] && docker rmi -f ${IMAGES}
  # local IMAGES=`docker images -q -f "label=app=${APP}"`
  # [ "$IMAGES" != ‘‘ ] && docker rmi -f ${IMAGES}

  docker build -t ${TAG} ${DOCKER_DIR}
}

function push() {
  echo "------------------------------ PUSH ------------------------------"

  docker push ${TAG}
  export SERVICE_NAME NAMESPACE IMAGE_URL
  envsubst <deploy/${APP}.tmpl || :
}

function all() {
  build
  push
}

function usage() {
  echo "Usage: $0 [build|push|all] [production|test]"
}

function main() {
  case ${CMD} in
  b*) build ;;
  p*) push ;;
  a*) all ;;
  *) usage ;;
  esac
}

init $@
main

配置好后且确保权限无误即可执行:

./build.sh all test

配置执行后会直接push镜像到harbor内(事先配置好)。

查看docker中的各种内容的命令:

docker ps

See ‘docker --help‘
MacBook-Pro:111$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

查看已经打出的镜像

docker images

MacBook-Pro:111$ docker images
REPOSITORY                             TAG                 IMAGE ID            CREATED             SIZE
registry.momenta.works/cla/milky-web   191202-test         1532be927f8d        5 hours ago         18.7MB
registry.momenta.works/cla/milky-web   191128-test         1af4615c4cb3        4 days ago          18.7MB
registry.momenta.works/cla/milky-web   191121-test         f6cb17d8b0a0        11 days ago         18.7MB
registry.momenta.works/cla/milky-web   191120-production   3e11cd30dd89        11 days ago         18.7MB
registry.momenta.works/cla/milky-web   191120-test         ee0909ecd9f7        11 days ago         18.7MB
registry.momenta.works/cla/milky-web   <none>              13993e12200a        12 days ago         18.7MB
registry.momenta.works/cla/milky-web   <none>              8de9f053335a        12 days ago         18.7MB
registry.momenta.works/cla/milky-web   <none>              7828f22eb355        12 days ago         18.7MB
registry.momenta.works/cla/milky-web   <none>              c23b51230cad        12 days ago         18.7MB
registry.momenta.works/cla/milky-web   <none>              f5169dc0f863        12 days ago         18.7MB
registry.momenta.works/cla/milky-web   <none>              eb5463875800        12 days ago         18.7MB
registry.momenta.works/cla/milky-web   <none>              618d7f09c2f6        12 days ago         18.7MB
registry.momenta.works/cla/milky-web   <none>              b682475e4d9b        12 days ago         18.7MB
registry.momenta.works/cla/milky-web   <none>              85420f94ff4c        12 days ago         18.7MB
registry.momenta.works/cla/milky-web   <none>              972cc2cc9c7c        12 days ago         18.7MB
registry.momenta.works/cla/milky-web   <none>              08098283428a        12 days ago         18.7MB
registry.momenta.works/cla/milky-web   191119-test         bdc5d28d724f        12 days ago         18.7MB
registry.momenta.works/cla/milky-web   191118-test         3aca38625579        13 days ago         18.7MB
registry.momenta.works/cla/milky-web   <none>              5b4dcdc14def        13 days ago         18.7MB
registry.momenta.works/cla/milky-web   <none>              f40db7e196fb        2 weeks ago         18.7MB
registry.momenta.works/cla/milky-web   <none>              ff2c5da90a90        2 weeks ago         18.7MB
registry.momenta.works/cla/milky-web   191116-test         c2e20e00fa04        2 weeks ago         18.7MB
registry.momenta.works/cla/milky-web   191115-test         2d0ebce7a82c        2 weeks ago         18.7MB
nginx                                  1.15-alpine         dd025cdfe837        6 months ago        16.1MB

将打好的镜像上传到相对应的harbor仓库中:

docker push registry.momenta.works/cla/milky-web:-test

在rancher中对相应的服务(微服务)edit相应的镜像地址即可

技术图片

以上是权限没有配置好情况下的操作

假如说我们的权限配置没有问题了,直接执行build.sh即可(省略中间步骤),最后在rancher中edit相应的镜像即可

 

未完待续(harbor与rancher的使用及配置会在近期附上)

Happy Hacking

部署基于Gitlab+Docker+Rancher+Harbor的前端项目这一篇就够了

标签:mon   简单   pull   迭代   view   快速   system   cad   meta   

原文地址:https://www.cnblogs.com/fqnb001/p/12369352.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!