day13 : argo gitops服务以及ingress (下)

昨天让服务能够在git commit推到master的branch下就立刻进行布署，但是仅就这一些功能其实没办法突显argo的优势，所以今天会再进阶的利用argo rollouts的功能让布属更加行云流水。

在开始之前要先知道一件事情，argocd 与 argo rollouts 两个是不相依的，不用argocd 也可以使用argo rollouts，argo rollouts的用途是在於完成服务的渐进式布署or蓝绿布署，那麽就来玩看看吧

安装argo rollouts

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

安装完成後，会发现多了很多关於argo 的crd可以使用，先来尝试看看简单的蓝绿布署，

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: app-name-rollouts
spec:
  replicas: 1
  revisionHistoryLimit: 2
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app-name
  strategy:
    blueGreen: 
      activeService: active-service
      previewService: preview-preview
      autoPromotionEnabled: false

基於这个做法，在app-name的deployment异动时，他会自动的做出一份preview的service，这时候可以搭配istio做流量转送让原本的服务正常运行，开发人员到preview的service验证功能，如果没有问题的话再promote让服务更新，那麽要如何promote呢？
有两种方法
透过argo rollouts的plugins 让k8s具有kubectl argo rollouts promote的功能，这样就可以kubectl argo rollouts promote app-name-rollouts -n ns，不过指令操作难免有些人不够熟悉，所以其实也可以透过介面的方式达成。
介面也同样的，可以透过kubectl argo rollouts dashboard的方式启动，只是这样就会占用到3100 port 这个刚好是loki使用的(不过其实不影响)，所以我选择让argo rollout dashboard 成为一个pod，官方提供了一个image quay.io/argoproj/kubectl-argo-rollouts:master ，把这个container包成deployment并且曝露出service，就可以轻易使用promote的功能罗。

argo rollouts其实也不仅是这样，可以透过更进阶一点的方式，让服务透过prometheus自动发现自己的流量是否可以promote，接下来就来做个示例

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: app-name
spec:
  replicas: 1
  revisionHistoryLimit: 2
  strategy:
    canary:
      analysis:
        templates:
        - templateName: service-check
        startingStep: 2 
        args:
        - name: service-name
          value: svc-name.ns-name.svc.cluster.local
      steps:
      - setWeight: 20
      - pause: {duration: 10} 
      - setWeight: 40
      - pause: {duration: 10}
      - setWeight: 60
      - pause: {duration: 10}
      - setWeight: 80
      - pause: {duration: 10}

基於以上的rollouts yaml，会利用到另一个crd AnalysisTemplate，这个crd可以协助进行一些简易的测试，像是从prometheus确认流量之类的，达成自动化的布署。

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: service-check
spec:
  args:
  - name: service-name
  metrics:
  - name: success-rate
    interval: 5m
    successCondition: result[0] >= 0.95
    failureLimit: 3
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          sum(irate(
            istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code!~"5.*"}[5m]
          )) / 
          sum(irate(
            istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5m]
          ))

根据这个示例，就会配合rollouts的内容每10秒切换一次，如果istio request回应不足95%就会算失败，自动化的完成布署作业。