drycc/workflow

The developer and operations friendly Kubernetes toolbox

Drycc workflow

Drycc Workflow is an open source Container as a Service (CaaS) that adds a developer-friendly layer to any Kubernetes cluster, making it easy to deploy and manage applications.

To get started with Drycc Workflow please read the Quick Start Guide.

Visit https://www.drycc.cc for more information on why you should use Drycc Workflow or learn about its features.

This repository contains the source code for Drycc Workflow documentation. If you're looking for individual components, they live in their own repositories.

Please see below for links and descriptions of each component:

• gateway - Workflow gateway charts
• passport - Workflow single sign on system
• controller - Workflow API server
• builder - Git server and source-to-image component
• imagebuilder - The builder for Container Image and CNCF Buildpacks based applications
• fluentbit - Backend log shipping mechanism for drycc logs
• postgres - The central database
• registry - The Container registry
• logger - The (in-memory) log buffer for drycc logs
• monitor - The platform monitoring components
• prometheus - The monitor database
• rabbitmq - RabbitMQ is a message broker used with controller celery
• storage - The in-cluster, kubernetes storage, s3 api compatible, hybrid storage system.
• workflow-cli - Workflow CLI drycc

We welcome your input! If you have feedback, please submit an issue. If you'd like to participate in development, please submit a pull request.

workflow's Issues

drycc.yaml support

build

• The variable passed when config is the build image(--build-arg)
• No need to use the docker field when using a single dockerfile or buildpack

run

• The statements that need to be executed before each deployment
• Image is optional, usually not available when there is no build item.
• Image can be an internal build name or an external image image

deploy

• It can be a dictionary type or a string, please refer to the example for details
• The string type defaults to one-to-one correspondence with build
• Image can be an internal build name or an external image image

example

build:
  docker:
    web: Dockerfile
    worker: worker/Dockerfile
  config:
    RAILS_ENV: development
    FOO: bar
run:
  command:
  - ./deployment-tasks.sh
  image: worker
deploy:
  web:
    command:
    - bash
    - -c
    args: bundle exec puma -C config/puma.rb
  worker:
    command:
    - bash
    - -c
    args:
    - python myworker.py
  asset-syncer:
    command:
    - bash
    - -c
    args:
    - python asset-syncer.py
    image: worker

The content of the file stored in the controller after being built by the builder in the example is:

build:
  docker:
    web: Dockerfile
    worker: worker/Dockerfile
  config:
    RAILS_ENV: development
    FOO: bar
run:
  command:
  - ./deployment-tasks.sh
  image: 127.0.0.1:7070/myapp/worker:git-123fsa1
deploy:
  web:
    command:
    - bash
    - -c
    args: bundle exec puma -C config/puma.rb
    image: 127.0.0.1:7070/myapp/web:git-123fsa1
  worker:
    command:
    - bash
    - -c
    args:
    - python myworker.py
    image: 127.0.0.1:7070/myapp/worker:git-123fsa1
  asset-syncer:
    command:
    - bash
    - -c
    args:
    - python asset-syncer.py
    image: 127.0.0.1:7070/myapp/worker:git-123fsa1

design

• Add the dryccfile field in api.model.build.Build
• release.image and deploy.<ptype>.image is optional, the rules are as follows:
  • release.image and deploy.<ptype>.image will be used first if it exists.
  • If there is a build field, refine the image based on the build field.
  • If none of the above conditions are met, the default image will be used, which is usually api.model.build.Build.image
  • If there is a build.docker field, then the run and deploy fields need to correspond to the build.docker field. If they do not correspond, it is necessary to specify.

drycc run give pod 20 minutes to execute, exceeding 20 minutes will raise a timeout exception

todo list:

1. should not raise timeout exception
2. drycc run type measure
3. drycc run type set limits
4. there are two modes: synchronous and asynchronous

[controller] drop ndg_httpsclient require

https://github.com/drycc/controller/blob/main/rootfs/api/models/certificate.py#L5

[controller] use cryptography replace pyOpenSSL

https://github.com/drycc/controller/blob/main/rootfs/api/models/certificate.py#L2

use Dockerfile entrypoint

I don't currently use entrypoints in Dockerfile, and I think this is a bug.

add volumes:client support

commands:

drycc volumes:client put xxx.file vol://s1/etc
drycc volumes:client get vol://s1/etc/xxx.file

Components:

• workflow-cli
• controller
• controller-go-sdk

Implementation:

• generate a temporary filer pod
• filer mounting volumes for operation

Reuse cm and secrets when upgrading

The following components need to be modified

• https://github.com/drycc/controller
• https://github.com/drycc/rabbitmq
• https://github.com/drycc/redis
• https://github.com/drycc/registry
• https://github.com/drycc/storage
• https://github.com/drycc/timeseries
• https://github.com/drycc/logger
• https://github.com/drycc/builder
• https://github.com/drycc/manager
• https://github.com/drycc/registry-proxy
• https://github.com/drycc/monitor
• https://github.com/drycc/fluentbit
• https://github.com/drycc/passport
• https://github.com/drycc/database

Add diagnostic mode for all chars

## Enable diagnostic mode in the deployment
##
diagnosticMode:
  ## @param diagnosticMode.enabled Enable diagnostic mode (all probes will be disabled and the command will be overridden)
  ##
  enabled: false
  ## @param diagnosticMode.command Command to override all containers in the deployment
  ##
  command:
    - sleep
  ## @param diagnosticMode.args Args to override all containers in the deployment
  ##
  args:
    - infinity