首页 文章 精选 留言 我的

精选列表

搜索[Harness工程],共10000篇文章
优秀的个人博客,低调大师

写给前端工程师看的Docker教程-实战篇

在上篇文章里,我们学习了Docker常用的命令和基本操作,现在可以开始实战了。 单页应用 前端工作中最常见的就是单页应用了。我们首先用create-react-app快速创建一个应用 npm i create-react-app -g create-react-app react-app cd react-app npm run start 可以看见正常启动的页面。 打包试一下 npm run build 可以看到本地生成了一个build目录,这就是最后线上运行的代码。 我们先在本地运行下build目录看看 npm i http-server -g http-server -p 4444 ./build 访问 http://localhost:4444 即可看到打包后的页面 单页应用Docker化 在react-app目录下新建Dockerfile .dockerignore和nginx.conf .dockerignore node_modules build dockerignore指定了哪些文件不需要被拷贝进镜像里,类似.gitignore。 我们知道单页应用的路由一般都被js托管,所以对于nginx需要特别配置nginx.conf server { listen 80; server_name localhost; location / { root /app/build; # 打包的路径 index index.html index.htm; try_files $uri $uri/ /index.html; # 防止重刷新返回404 } error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } } Dockerfile # 基于node11 FROM node:11 # 设置环境变量 ENV PROJECT_ENV production ENV NODE_ENV production # 安装nginx RUN apt-get update && apt-get install -y nginx # 把 package.json package-lock.json 复制到/app目录下 # 为了npm install可以缓存 COPY package*.json /app/ # 切换到app目录 WORKDIR /app # 安装依赖 RUN npm install --registry=https://registry.npm.taobao.org # 把所有源代码拷贝到/app COPY . /app # 打包构建 RUN npm run build # 拷贝配置文件到nginx COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 # 启动nginx,关闭守护式运行,否则容器启动后会立刻关闭 CMD ["nginx", "-g", "daemon off;"] 需要特别注意的是: COPY package*.json /app/ RUN npm install COPY . /app 我们单独把package.json文件先拷贝到app,安装完依赖,然后才把所有的文件拷贝到app,这是为什么? 这是为了充分利用docker缓存 COPY . /app RUN npm install 如果这么写,那么每一次重新构建镜像,都需要下载一次npm包,这是非常浪费时间的!而把package.json与源文件分隔开写入镜像,这样只有当package.json发生改变了,才会重新下载npm包。 当然缓存有时候也会造成一些麻烦,比如在进行一些shell操作输出内容时,由于缓存的存在,导致新构建的镜像里的内容还是旧版本的。 我们可以指定构建镜像时不使用缓存 docker build --no-cache -t deepred5/react-app . 最佳实践是在文件顶部指定一个环境变量,如果希望不用缓存,则更新这个环境变量即可,因为缓存失效是从第一条发生变化的指令开始。 打包镜像 docker build -t deepred5/react-app . 启动容器 docker run -d --name my-react-app -p 8888:80 deepred5/react-app 访问 http://localhost:8888 即可看到页面 访问 http://localhost:8888/deepred5, 也可以看见页面,说明nginx防刷新配置生效了! 多层构建 我们之前写的Dockerfile其实是有些问题的: 镜像基于node11,但是整个镜像用到node环境的地方只是为了前端打包,真正启动的是Nginx。镜像里的项目源代码以及node_modules其实根本没有用,这些冗余文件造成了镜像的体积变得非常庞大。 而我们仅仅需要打包出来的静态文件以及启动一个静态服务器Nginx即可。 这时就可以使用multi-stage多层构建。 新建一个Dockerfile.multi # node镜像仅仅是用来打包文件 FROM node:alpine as builder ENV PROJECT_ENV production ENV NODE_ENV production COPY package*.json /app/ WORKDIR /app RUN npm install --registry=https://registry.npm.taobao.org COPY . /app RUN npm run build # 选择更小体积的基础镜像 FROM nginx:alpine COPY nginx.conf /etc/nginx/conf.d/default.conf COPY --from=builder /app/build /app/build 这个文件里,我们使用了两个FROM基础镜像,第一个node:alpine仅仅作为打包环境,真正的基础镜像是nginx:alpine 打包镜像 # -f 指定使用Dockerfile.multi进行构建 docker build -t deepred5/react-app-multi . -f Dockerfile.multi 启动容器 docker run -d --name my-react-app-multi -p 8889:80 deepred5/react-app-multi 访问 http://localhost:8889 即可看到页面 查看镜像大小 docker images deepred5/react-app-multi docker images deepred5/react-app 可以发现,两者的大小相差巨大。 deepred5/react-app镜像有1G多,而deepred5/react-app-multi只有20多M 主要原因是:deepred5/react-app的基础镜像node:11就有900M,而deepred5/react-app-multi的基础镜像nginx:alpine只有20M。由此可见多层构建对于减少镜像大小是非常有帮助的。 Node应用 前端有时也会参与到Node BFF层的开发。我们来创建一个Node结合Redis的简单项目 mkdir node-redis cd node-redis npm init -y npm i koa koa-router ioredis touch index.js node-redis/index.js const Koa = require('koa'); const Router = require('koa-router'); const Redis = require("ioredis"); const app = new Koa(); const router = new Router(); const redis = new Redis({ port: 6379, host: '127.0.0.1' }); router.get('/', (ctx, next) => { ctx.body = 'hello world.'; }); router.get('/api/json/get', async (ctx, next) => { const result = await redis.get('age'); ctx.body = result; }); router.get('/api/json/set', async (ctx, next) => { const result = await redis.set('age', ctx.query.age); ctx.body = { status: result, age: ctx.query.age } }); app .use(router.routes()) .use(router.allowedMethods()); app.listen(3000, () => { console.log('server start at localhost:3000'); }) 我们首先需要本地安装Redis,然后启动redis redis-server 启动Node项目 node index.js 访问 http://localhost:3000/ 即可看到页面 访问 http://localhost:3000/api/json/set?age=2 ,我们就向Redis里设置age的值为2 访问 http://localhost:3000/api/json/get ,我们就取得Redis里age的值 Node应用Docker化 首先我们来思考下,这个后端应用涉及Node和Redis。如果我们要部署到Docker里,应该怎么构建镜像? 方案一:基于一个最基础的ubuntu镜像,然后我们在其中安装Node和Redis,这样Node和Redis之间就可以进行通信了。这种方案只需要启动一个容器,因为Node和Redis已经在这个容器里了。 方案二:我们基于Redis镜像启动一个容器,专门用来跑Redis。基于Node镜像再启动一个容器,专门用来跑Node。 Docker的理念更倾向于方案二。我们希望一个镜像专注于做一件事,现在流行的微服务,微前端也是这种思想。 我们之前说过每个容器都是相互隔离的,通过映射端口才能访问容器里的网络应用。但是容器和容器之间怎么进行通信呢? Docker里使用Networking进行容器间的通信 Networking # 创建一个app-test网络 docker network create app-test 我们只需要把需要通信的容器都加入到app-test网络里,之后容器间就可以互相访问了。 docker run -d --name redis-app --network app-test -p 6389:6379 redis docker run -it --name node-app --network app-test node:11 /bin/bash 我们创建了两个容器,这两个容器都在app-test网络里。 我们进入node-app容器里,然后ping redis-app,发现可以访ping通,说明容器间可以通信了! 我们修改之前的代码: const redis = new Redis({ port: 6379, host: 'db', }); redis的host改为db 新建一个Dockerfile FROM node:11 COPY package*.json /app/ WORKDIR /app RUN npm install COPY . /app EXPOSE 3000 CMD ["node","index.js"] 构建镜像 docker build -t deepred5/node-redis-app . 启动容器 # 创建网络 docker network create app-test # 启动redis容器 docker run -d --name db --network app-test -p 6389:6379 redis # 启动node容器 docker run --name node-redis-app -p 4444:3000 --network app-test -d deepred5/node-redis-app 访问 http://localhost:4444/ 即可看到页面 还记得我们之前做的react-app单页应用吗?我们可以也把这个应用加入到app-test网络里来,这样前端单页应用也可以访问后端了! 修改react-app目录下的nginx.conf server { listen 80; server_name localhost; location / { root /app/build; # 打包的路径 index index.html index.htm; try_files $uri $uri/ /index.html; # 防止重刷新返回404 } location /api { proxy_pass http://node-redis-app:3000; #后台转发地址 } } 重新构建镜像 docker build -t deepred5/react-app-multi . -f Dockerfile.multi 启动容器 docker run -d --name my-react-app-multi --network app-test -p 9999:80 deepred5/react-app-multi 访问 http://localhost:9999/api/json/set?age=55 成功返回数据 Docker compose 我们现在这个项目有3个启动镜像: deepred5/react-app-multi 前端单页应用 redis 数据缓存 deepred5/node-redis-app 后端服务,访问redis,同时给前端提供接口 如果要把这个项目完整的启动起来,按照顺序需要这样启动: # 启动redis容器 docker run -d --name db --network app-test -p 6389:6379 redis # 启动node容器 docker run --name node-redis-app -p 4444:3000 --network app-test -d deepred5/node-redis-app # 启动前端容器 docker run -d --name my-react-app-multi --network app-test -p 9999:80 deepred5/react-app-multi 这还仅仅只是3个容器的项目,如果容器再多,启动就变得非常复杂了! 这时,就需要docker compose出场了。 首先需要安装docker compose,安装完成之后 我们新建一个my-all-app目录,然后新建docker-compose.yml mkdir my-all-app cd my-all-app touch docker-compose.yml version: '3.7' services: db: image: redis restart: always ports: - 6389:6379 networks: - app-test node-redis-app: image: deepred5/node-redis-app restart: always depends_on: - db ports: - 4444:3000 networks: - app-test react-app-multi: image: deepred5/react-app-multi restart: always depends_on: - node-redis-app ports: - 9999:80 networks: - app-test networks: app-test: driver: bridge # 启动所有容器 docker-compose up -d # 停止所有容器 docker-compose stop 访问 http://localhost:9999 查看前端页面 访问 http://localhost:4444 查看后端接口 可以看见,使用docker-compose.yml配置完启动步骤后,启动多容器就变得十分简单了。 参考 如何使用docker部署前端应用 第一本Docker书 修订版

优秀的个人博客,低调大师

千亿级的数据难题,优酷工程师怎么解决?

阿里妹导读:优酷一天的日志量会达到千亿级别,面对如此大的数据样本,2017年5月,优酷完成了从Hadoop迁移到阿里云MaxCompute,实现计算消耗和储存的消耗呈下降趋势,得到了非常大的收益。今天,阿里数据技术专家门德亮给大家做个分享,从为什么要用MaxCompute,到优酷的业务场景下典型的方案及应用分析,聊聊迁移后对业务及平台的具体价值。本文内容根据演讲视频以及PPT整理而成,希望对你有所助益。 大家好,我是门德亮,很荣幸,我正好见证了优酷从没有MaxCompute到有的,这样一个历程,我们正好是在快到5年的时候,做了从Hadoop到MaxCompute的这样一个升级。 2016年5月到2019年5月优酷的发展历程。整个用户数,还有表的数据,实际上是呈指数式增长的。但是在2017年5月,当优酷完成了整个Hadoop迁移MaxCompute后,优酷的计算消耗,还有储存的消耗实际上是呈下降趋势的,整个迁移得到了非常大的收益。 下面说一下优酷的业务特点。 第一个特点是大数据平台整个的用户复杂度,不止是数据的同学和技术的同学在使用,还会包括一些BI同学,测试同学,甚至产品运营都可能去使用这个大数据的平台。 第二个特点就是业务复杂,优酷是一个视频网站,它有非常复杂的业务场景,从日志分类上,除了像页面浏览,还会有一些播放相关的数据、性能相关的数据。从整个的业务模式上,有直播、有会员、有广告、有大屏等这样一些非常不一样的场景。 第三个特点,就是数据量非常巨大,一天的日志量会达到千亿级别,这是一个非常庞大的数据量,而且会做非常复杂的计算。 第四个比较有意思,不管是小公司、大公司,对成本的意识是非常高的。优酷也是有非常严格的预算,包括在阿里集团内是有非常严格的预算系统的,但是我们也经常会去做一些重要的战役,像双十一战役,像我们暑期的世界杯战役,还有春节也会搞各种战役。这其实对计算资源的弹性要求是非常高的。 基于上面的优酷的业务特点,我整理了MaxCompute可以完美的支持我们业务的几个特点。 简单易用。 完善的生态。 性能非常强悍。 资源使用非常弹性。 第一个特点,简单易用。MaxCompute有一个非常完整的链路,不管是从数据开发,还是数据运维,包括数据集成,数据质量的管控,还有整个数据地图,数据安全。当年优酷从Hadoop迁到MaxCompute之后,我们最大的体会是不用经常自己半夜起来去维护集群了,不用去跑任务了,之前别人提一个需求过来,我可能要排几周,现在我可以告诉他,我给你马上跑一下,就可以出来了。包括之前像分析师BI还要登录客户端,写脚本,自己写调度,经常会说我的数据今天为什么没出来?包括高层看的数据,可能要到12点钟才能出来。而现在基本上所有重要的数据都会在7点钟产出,包括一些基本的业务需求,其实分析师或者产品,他们自己都可以实现了,不需要所有需求都提到数据这边。 第二个特点,完整的生态。优酷在2017年之前是完全基于Hadoop的生态,迁到MaxCompute之后,是基于阿里云提供的Serverless大数据服务的生态。大家可以在开源上看到的组件,在整个的MaxCompute上都是有的,而且比开源的要更好用、更简单。从架构图上可以看到,我们中间是MaxCompute,左侧依赖的Mysql、Hbase、ES、Redis这些都是由同步中心去做一个双向的同步。右侧会有资源管理、资源监控、数据监控,包括数据资产,还有一些数据规范。我们下层的数据输入,包括一些集团的采集工具,再往上边,有提供给开发人员用的DataWorks,包括一些命令行的工具,有提供给BI人员用的QuickBI及数据服务。 第三个特点,强悍的性能,MaxCompute支撑了优酷EB级的数据存储,千亿级的数据样本分析,包括千亿级的数据报表,10W级实例的并发、任务。这些在之前维护Hadoop的时候,是想都不敢想的。 第四个特点,资源使用的弹性。我们在2016年迁移之前,其实优酷的Hadoop集群规模已经达到了一千多台,这个当时还是一个比较大的规模。当时我们遇到了很多问题,包括像NameNode 这种内存的问题,机房没有办法再扩容的问题,当时是非常痛苦的,包括一些运维管理上面的问题。我们不断地去问运维要资源,运维说你们已经花了资源,多少钱。我们面临的问题是计算资源如何按需使用,夜里的作业很多,到了午后,整个集群都空下来了,没有人用,造成了浪费。其实MaxCompute完美地解决了这个问题。 第一个,它是按用量计费的,不是说给你多少台机器,就收你多少钱,是你用了多少资源收多少钱的,在成本上来说,比自己去维护集群,可能是一个砍半(降50%)的收益。 第二个,实际上MaxCompue计算资源是可以分时的,比如说生产队列,凌晨的时候会调高一些,保证报表能够尽快出来。到白天时候,让开发的计算资源高一些,可以让分析师、开发去临时跑一些数据,会更顺畅一些。 第三个,MaxCompute快速的扩容能力,比如说突然有一个比较强的业务需求,发现数据跑不动了,计算资源不够,所有的队列都堵死了,这个时候其实可以直接跟运维说一声,帮忙一键扩容,两秒钟敲一个命令就搞定了。这样,所有的资源可以迅速地消化下去。 这张图实际上是优酷,包括可能现在阿里集团内部一些非常典型的技术架构图。中间可以看到,MaxCompute在中间核心的位置,左侧主要是一个输入,右侧是一个输出的趋向,绿色的线是一个实时的链路,包括现在我们从整个的数据源上,比如DB也好或者服务器的本地日志Log也好,我们通过TT&Datahub存储到MaxCompute上面做分析。当然现在非常火的Flink实时计算,其实是作为一个实时处理的链路。 包括DB的同步,除了实时的链路,DB也会去通过按天/按小时,把数据同步到MaxCompute,数据计算结果也可以同步到Hbase、Mysql这种DB上面。再通过统一的服务层对应用提供服务。下面这个是机器学习Pai做的一些算法训练,再把训练的结果通过OSS传到一个算法的应用上面去。 这张图可能也是业界比较流行的一个数仓分层的图,因为我们这边是数据中台,所有的数据都是统一从ods层cdm层,然后ads层,去一层一层地往上去做精细,再到最上面,通过接口服务、文件服务、SQL服务,去提供多样化的服务。再往上面,提供对内的一些数据产品,对高管、对小二,可能还有一些对外的,比如说像优酷的播放数,包括热度这些对应用的数据。 这张图其实就是我们从Hadoop迁到MaxCompute平台上以来,两个非常经典的案例。我们通过数据中台对不同场景的用户打通,来去赋能到两个不同的场景,提升业务价值。 第二个,可能是内部的,我们通过优酷,还有集团内部的一些BU去做换量,我们通过统一的标签去做样本放大,把优酷的量导给其它的BU,把其它BU的量导给优酷,这样去达到一个共赢的效果。 这张图是大部分互联网公司不太会涉及到的,就是关于反作弊的问题。这个是我们在MaxCompute做的一个反作弊的架构,通过原始的数据去提取它的特征,然后再通过算法模型,包括机器学习、深度学习、图模型去支持流量反作弊、渠道反作弊等等。再通过业务场景上反作弊的监控工具,把监控到的作弊信息去打一个黑白样本,再把这个黑白样本跟特征一起来不断地迭代优化算法模型。同时针对算法模型,做一个模型的评价,不断来完善反作弊体系。 最后一点,其实还是跟成本相关,在日常使用中,一定是有小白用户或者一些新来的用户去错误地使用或者不在乎地使用一些资源,比如经常会有一些实习生或者是非技术的同学,如分析师,一个SQL消费比较高,这个其实是非常浪费资源,而且可能他一个任务,让其他所有人的任务都在这儿等着排队,实际上我们会去对整个的资源做一个治理。 从节点的粒度上,通过大数据来治理大数据,我们可以算出哪些表产出来之后,多少天没有被读取的,包括它的访问跨度可能没有那么大的,我们会去做下线或者去做治理,有一些业务场景可能并不是非常的重要或者它的时间要求没有那么高,比如一些算法训练,可以去做一些错峰的调度,保证水位不要太高。从MaxCompute任务的角度,可以算出哪些任务有数据倾斜、哪些数据可能会有相似计算,哪些任务需要去做MapJoin,哪些任务需要去做一些裁剪,然后来节省它的IO。还有哪些任务会去做暴力扫描,扫一个月、扫一年的数据,哪些数据可能会有这样一个数据膨胀,比如说它做了CUBE之类的这种复杂计算,一些算法模型的迭代;我们通过数据计算出来的这些迹象,去反推用户,来去提高它的这样一个数据的质量分,来去达到我们降低整个计算资源的目的。 在计算平台的角度,我们也持续地在使用MaxCompute推出的一些非常高级的用法,比如我们这边的HBO、Hash Cluster、Aliorc; 第一个,HBO就是我们基于一个历史的优化,这样避免了用户不知道怎么调参,我可能为了自己任务快一点,就调一个特别大的参数,这样的话,对集成的资源是非常浪费的。通过这个功能,用户就不用去调参数,集群自动调好,用户就写好自己业务逻辑就好了。 第二个,可能就是最近两年推出的Hash Cluster,当时在使用Hadoop的时候经常会出现,两个大表Join的时候计算不出来,这个Hash Cluster其实是一个优化的利器。大表跟小表Join,可以做一些分发,做一些优化。大表跟大表就涉及到一个排序的问题。这个Hash Cluster,实际上就是提前把数据排好,中间省掉很多计算环节,来达到效率提升的目的。 第三个,Aliorc,在一些固定的场景上面,可以稳定的提升20%的计算效率。 第四个,Session。对一些比较小的数据,直接就放到SSD或缓存里面,一个节点下游有100个叶子场景,是非常友好的,因为低延迟秒出结果。同时,优酷也在使用Lightning解决计算加速,这个是在一个计算架构方案上的优化,它是一个MPP的架构。 最后一页是存储的优化,因为像一些关键的原始数据或者是需要审计的数据是不能删的,永久不能删的。实际上就会造成我们数据存储的趋势是一直往上不减的,计算会在某一个时间点达到一个平衡。当前用这么多的计算资源,再往后,其实应该也不会再大涨了,比如说旧的业务逻辑下掉了,会换新的业务逻辑,这样会保持在一个相对平稳的波动上面。 但是储存,因为它有一些历史的数据是永远不能删的,可能会出现一直在增长,而且是指数级的。所以我们也会持续关注存储的情况,还是通过大数据来治大数据,去看哪些表的访问跨度比较小,来去做生命周期的优化,来去控制它的增速。还有刚才提到的Aliorc,实际上也是做压缩的。我们会去做一些大字段的拆分,来提高压缩的比例。 共建大数据生态,企业级大数据平台开发者版已正式发布,点击文末“阿里技术”阅读原文立即申请。 原文发布时间为: 2019-07-9本文作者:阿里技术本文来自云栖社区合作伙伴“ 阿里技术”,了解相关信息可以关注“ 阿里技术”。

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册