gitlawr

Compression Comparison

Original file: 2.4G docker images tar file

format	compressed size	ratio	compress time	decompress time
bzip2	645M	26.6%	4m13s	1m33s
lz4	1.1G	42.3%	7s	12s
gzip	728M	30.0%	1m50s	21s
zstd	670M	27.6%	16s	10s

gitlawr

Use external DB from Helm stable chart for Global Registry

Steps:

1. Enable Helm stable catalog
2. Deploy a postgresql app with the following answers:

#if no pv available, set: persistence.enabled=false
service.type=NodePort
postgresqlUsername=postgres

gitlawr

stages:
- name: Deploy to external K8S
  steps:
  - runScriptConfig:
      # Any images with kubectl binary packaged
      image: lawr/kubectl 
      shellScript: |-
        mkdir -p ~/.kube
 # This helps to hide the file content in build logs

gitlawr

Example multiclusterapp command flow:

$ rancher multiclusterapps -h
Operations with multi-cluster apps

Usage:
   rancher multiclusterapps command [command options] [arguments...]

Commands:
     ls                  List multi-cluster apps

gitlawr

Pipeline Volume Support

Background

We've got users constantly asking for caching files between pipeline builds. Currently, when a build is finished, the build pod will be removed and all intermediate files are ephemeral. For instance, when a maven build is done the second time, users would like to have local cache and do not need to fetch dependencies again. They can setup private maven repository now to speed up the process but it still causes additional network traffic and extra time.

Design Proposal

For multi-tenancy we don't want to support host-path volume, and we don't need dynamic provisioning regarding pipeline usecases. So the plan is to support three volume types: existing PVCs/secrets/configmaps.

gitlawr

Plugin Framework in Rancher Pipeline

Objective

Pipeline currently provides extensibility by using different context images in pipeline steps. An image with certain utilities can be considered as a plugin. But we lack a centralized place to maintain available plugins, either provided by Rancher or community users. Also, the user experience for using different plugins can be improved so that users with poor experience in container/kubernetes can use existing util images more easily.

Proposed Design

We use questions files to describe the usage of a pipeline plugin. An example for using drone s3 plugin:

gitlawr

Pipeline CD Design

1. CD on K8S using existing tools

Drone

There're some Drone plugins for integration with K8S:

Drone-Kubernetes: upgrade a Kubernetes deployment with a newer version of an image.

gitlawr

Pipeline API

API Design

Cluster level pipeline configs

ClusterPipeline(CRUD),

action=authapp{Input:GithubConfig+code,Output:clusterPipeline}, action=authuser{Input:code,Output:sourcecodecredential}, action=deploy,destroy,revokeapp

gitlawr

Pipeline API

API Design

Cluster level pipeline configs

ClusterPipeline(CRUD)

HTTP/1.1 POST /v3/clusters/cluster-id/clusterpipelines

gitlawr

https://www.netsarang.com/download/down_xfp5.html?token=UzJ2VGJFS0J0bU1aKzU2SDZCTE9iUUBGUjlpQ0M2TkF0TGdGZ3dnN1NzaXRB