一、k8s部署无状态的魔方游戏
通过ACK集群部署一个无状态工作负载Deployment
最主要的一步是从指定的位置拉取镜像 ，指定资源配置及服务端口和容器端口
registry.cn-hangzhou.aliyuncs.com/acr-toolkit/ack-cube
在网络-Service 功能菜单中找到创建的服务的外部端点
至此，一个魔方游戏服务部署完成，可以通过外部端点进行去访问了
后面体验了一下服务的监控应用
运维管理中的Prometheus监控
没有特定的场景需求，也就是去点吧点吧去看看热闹
二、docker镜像管理
2.1 安装docker
# 添加docker依赖库yum install -y yum-utils device-mapper-persistent-data lvm2 # 添加docker ce的软件源信息yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo # 安装docker ceyum makecache fast && yum -y install docker-ce # 启动docker服务systemctl start docker # 配置镜像加速器,此处也可以换成自己的镜像加速器tee /etc/docker/daemon.json <<-'EOF'{ "registry-mirrors": ["https://registry.docker-cn.com"] } EOF # 重启docker服务systemctl restart docker
2.2 创建Dockerfile
省略创建Dockerfile具体过程
基于Dockerfile文件去build，指定当前路径.
docker build . -t demo:v1 # docker run 运行镜像docker run -d-p8000:80 demo:v1 # 删除镜像，需要先stop依赖于这个镜像的容器docker rm-f$(docker ps -a | grep "demo:v1" | awk '{print $1}')
2.3 镜像推送至远程仓库
docker login --username="用户名" registry.cn-hangzhou.aliyuncs.com # 标记本地镜像，将其归入远程仓库docker tag demo:v1 registry.cn-hangzhou.aliyuncs.com/space_test/demo:v1 # 将本地镜像推送至远程仓库docker push registry.cn-hangzhou.aliyuncs.com/space_test/demo:v1 # 拉取指定版本的远程镜像docker pull registry.cn-hangzhou.aliyuncs.com/space_test/demo:v1 # 运行拉取的指定镜像docker run -d-p8000:80 registry.cn-hangzhou.aliyuncs.com/space_test/demo:v1
大概就是安装docker，创建Dockerfile，镜像制作docker build，容器运行docker run
镜像标记docker tag，镜像删除docker rm，镜像推送docker push，镜像拉取docker pull
三、混沌工程-故障演练(AHAS Chaos)
对于这一部分，坑坑好多，一个是产品的操作界面迭代更新与体验手册的文档不太一样
最致命的是根据体验手册进行不下去了，这是最无gai的~~~
在创建AHAS应用时，菜单名称不一致，由应用目录变为了应用市场。只能说产品更新迭代的速度太快了。
在部署AHAS服务时，操作也有一点小变化。
这两者的变化都是小细节，影响不大。
在创建故障演练时，下拉选择服务及服务组时，发现下拉选项是空的。
开始第一次操作卡壳了，就放弃了~~~
再后来操作时，就发现，可以选择服务了。
实际上，右侧也给了提示“找不到应用”，选择“应用接入”
在这个中就给出了解决的方案
再到后面的操作，大都是在看新奇的热闹，毕竟没接触过，也是自己能力有限~~~
再到后面的故障演练，创建了一个依赖治理的演练，扫描服务之间的依赖关系。
下面的提示说：近1分钟依赖关系无变化，可停止分析
然而，自己演练始终没有出现依赖关系，后面的就放弃了
每一期的结束，最刺激的应该是秒没的鼠标领取活动
但是这一期出了些许的故障，正常发放是在每一期的最后一天的10点卡点出现
这一期抢了个寂寞，有点懵。
先是0点之后就能领取了，发现这个问题之后，就将剩下的，放到了10点发放，然而对于我这个蹲点刷新的来说，10点刷新了个寂寞。站到将来去回看历史的角度，才知道不是在10点卡点发放的，往后推迟了半分钟的样子~~~
由此，给自己一个警醒，对于并发的“抢”活动来说，像优惠券的“抢”活动，设置好活动的开始时间，并且做好数量的准确，做到不少发，不超发~~~
不然会给用户带来surprise的体验
