chore(workflow): use podman replace docker

Author: duanhongyi

.woodpecker/publish-docs.yml

@@ -7,7 +7,7 @@ pipeline:
 - name: build-docs
   image: bash
   commands:
-  - make docker-build docker-build-docs
+  - make podman-build podman-build-docs
   - cp _scripts/* _build/html
   - cd _build/html && echo "www.drycc.cc" > CNAME  && echo "drycc.cc" >> CNAME && git init
   secrets:
@@ -22,7 +22,7 @@ pipeline:
   image: bash
   commands:
   - chown -R root:root _build/html
-  - docker run --rm
+  - podman run --rm
       -e DRONE_COMMIT_AUTHOR="$CI_COMMIT_AUTHOR"
       -e DRONE_COMMIT_AUTHOR_EMAIL="$CI_COMMIT_AUTHOR_EMAIL"
       -e PLUGIN_SSH_KEY="$SSH_DEPLOY_KEY"
@@ -34,7 +34,7 @@ pipeline:
       -e PLUGIN_COMMIT_MESSAGE="init repo"
       -v "$(pwd):$(pwd)"
       -w "$(pwd)"
-      appleboy/drone-git-push
+      docker.io/appleboy/drone-git-push
   secrets:
   - ssh_deploy_key
   when:

Makefile

@@ -13,7 +13,7 @@ VERSION ?= git-$(shell git rev-parse --short HEAD)
 IMAGE := ${SHORT_NAME}:${VERSION}
 REPO_PATH := github.com/drycc/${SHORT_NAME}
 DEV_ENV_WORK_DIR := /src/${REPO_PATH}
-DEV_ENV_PREFIX := docker run --rm -v ${CURDIR}:${DEV_ENV_WORK_DIR} -w ${DEV_ENV_WORK_DIR} -p 8000:8000
+DEV_ENV_PREFIX := podman run --rm -v ${CURDIR}:${DEV_ENV_WORK_DIR} -w ${DEV_ENV_WORK_DIR} -p 8000:8000
 DEV_ENV_CMD := ${DEV_ENV_PREFIX} ${DEV_ENV_IMAGE}
 
 BUILD_CMD := $(MKDOCSBUILD) --site-dir $(BUILDDIR) && \
@@ -39,17 +39,17 @@ deps:
 test: build
 	$(TEST_CMD)
 
-docker-build-docs:
+podman-build-docs:
 	$(shell chown -R 1001:1001 ${CURDIR})
 	$(DEV_ENV_CMD) ${IMAGE} $(BUILD_CMD)
 
-docker-test: docker-build-docs
+podman-test: podman-build-docs
 	${DEV_ENV_CMD} ${IMAGE} $(TEST_CMD)
 
-docker-build:
-	docker build ${DOCKER_BUILD_FLAGS} --build-arg CODENAME=${CODENAME} -t ${IMAGE} .
+podman-build:
+	podman build --build-arg CODENAME=${CODENAME} -t ${IMAGE} .
 
-docker-serve:
+podman-serve:
 	${DEV_ENV_CMD} ${IMAGE} $(MKDOCSSERVE)
 
-run: docker-build docker-serve
+run: podman-build podman-serve

README.md

@@ -14,10 +14,10 @@ Please see below for links and descriptions of each component:
 - [passport](https://github.com/drycc/passport) - Workflow single sign on system
 - [controller](https://github.com/drycc/controller) - Workflow API server
 - [builder](https://github.com/drycc/builder) - Git server and source-to-image component
-- [imagebuilder](https://github.com/drycc/imagebuilder) - The builder for [Docker](https://www.docker.com/) and [CNCF Buildpacks](https://buildpacks.io/) based applications
+- [imagebuilder](https://github.com/drycc/imagebuilder) - The builder for Container Image and [CNCF Buildpacks](https://buildpacks.io/) based applications
 - [fluentbit](https://github.com/drycc/fluentbit) - Backend log shipping mechanism for `drycc logs`
 - [postgres](https://github.com/drycc/postgres) - The central database
-- [registry](https://github.com/drycc/registry) - The Docker registry
+- [registry](https://github.com/drycc/registry) - The Container registry
 - [logger](https://github.com/drycc/logger) - The (in-memory) log buffer for `drycc logs`
 - [monitor](https://github.com/drycc/monitor) - The platform monitoring components
 - [prometheus](https://github.com/drycc/prometheus) - The monitor database
@@ -44,7 +44,7 @@ The Drycc project welcomes contributions from all developers. The high level pro
 
 ## Requirements
 
-The documentation site requires either a local installation of [MkDocs][] or access to Docker.
+The documentation site requires either a local installation of [MkDocs][] or access to Container.
 
 ### Local Installation
 
@@ -56,13 +56,13 @@ make deps
 
 ## Building Documentation
 
-To build the documentation run: `make build` or `make docker-build`.
+To build the documentation run: `make build` or `make podman-build`.
 
 ## Serve Documentation Locally
 
-To serve documenation run: `make serve` or `make docker-serve`.
+To serve documenation run: `make serve` or `make podman-serve`.
 
-Then view the documentation on [http://localhost:8000](http://localhost:8000) or `http://DOCKER_IP:8000`.
+Then view the documentation on [http://localhost:8000](http://localhost:8000) or `http://PODMAN_IP:8000`.
 
 [k8s-home]: http://kubernetes.io
 [install-k8s]: http://kubernetes.io/gettingstarted/

charts/workflow/values.yaml

@@ -62,7 +62,7 @@ global:
   #
   # Valid values are:
   # - on-cluster: Run registry within the Kubernetes cluster
-  # - off-cluster: Use registry outside the Kubernetes cluster (example: dockerhub,quay.io,self-hosted)
+  # - off-cluster: Use registry outside the Kubernetes cluster (example: drycc registry,self-hosted)
   registryLocation: "on-cluster"
   # Prefix for the imagepull secret created when using private registry
   registrySecretPrefix: "private-registry"

mkdocs.yml

@@ -30,7 +30,7 @@ nav:
     - Deploying Apps: applications/deploying-apps.md
     - Buildpacks: applications/using-buildpacks.md
     - Dockerfiles: applications/using-dockerfiles.md
-    - Docker Images: applications/using-docker-images.md
+    - Container Images: applications/using-container-images.md
     - Managing App Processes: applications/managing-app-processes.md
     - Managing App Configuration: applications/managing-app-configuration.md
     - Managing App Lifecycle: applications/managing-app-lifecycle.md

src/applications/deploying-apps.md

@@ -4,7 +4,7 @@ An [Application][] is deployed to Drycc using `git push` or the `drycc` client.
 
 ## Supported Applications
 
-Drycc Workflow can deploy any application or service that can run inside a Docker container.  In order to be scaled
+Drycc Workflow can deploy any application or service that can run inside a container.  In order to be scaled
 horizontally, applications must follow the [Twelve-Factor App][] methodology and store any application state in external
 backing services.
 
@@ -46,13 +46,13 @@ Dockerfiles are a powerful way to define a portable execution environment built
 Learn how to deploy applications [using Dockerfiles](../applications/using-dockerfiles.md).
 
 
-### Docker Image
+### Container Image
 
-Deploying a Docker image onto Drycc allows you to take a Docker image from either a public
+Deploying a Container image onto Drycc allows you to take a Container image from either a public
 or a private registry and copy it over bit-for-bit, ensuring that you are running the same
 image in development or in your CI pipeline as you are in production.
 
-Learn how to deploy applications [using Docker images](../applications/using-docker-images.md).
+Learn how to deploy applications [using Container images](../applications/using-container-images.md).
 
 ## Tuning Application Settings
 

src/applications/managing-app-processes.md

@@ -28,10 +28,10 @@ Dockerfile's `CMD` directive unmodified:
     CMD python -m SimpleHTTPServer 5000
     EXPOSE 5000
 
-For the above Dockerfile-based application, the `cmd` process type would run the Docker `CMD` of `python -m SimpleHTTPServer 5000`.
+For the above Dockerfile-based application, the `cmd` process type would run the Container `CMD` of `python -m SimpleHTTPServer 5000`.
 
-Applications utilizing [remote Docker images][docker image], a `cmd` process type is also implied, and runs the `CMD`
-specified in the Docker image.
+Applications utilizing [remote Container images][container image], a `cmd` process type is also implied, and runs the `CMD`
+specified in the Container image.
 
 !!! note
     The `web` and `cmd` process types are special as they’re the only process types that will
@@ -60,7 +60,7 @@ web: bundle exec ruby web.rb -p ${PORT:-5000}
 sleeper: sleep 900
 ```
 
-If you are using [remote Docker images][docker image], you may define process types by either running `drycc pull` with a
+If you are using [remote Container images][container image], you may define process types by either running `drycc pull` with a
 `Procfile` in your working directory, or by passing a stringified Procfile to the `--procfile` CLI option.
 
 For example, passing process types inline:
@@ -152,7 +152,7 @@ scenic-icehouse-web-3291896318-background-yf8kh up (v2)
 ```
 
 !!! note
-    The default process type for Dockerfile and Docker Image applications is 'cmd' rather than 'web'.
+    The default process type for Dockerfile and Container Image applications is 'cmd' rather than 'web'.
 
 Scaling a process down, by reducing the process count, sends a `TERM` signal to the processes, followed by a `SIGKILL`
 if they have not exited within 30 seconds. Depending on your application, scaling down may interrupt long-running HTTP
@@ -246,14 +246,14 @@ Scale up can only happen if there was no rescaling within the last 3 minutes. Sc
 ## Web vs Cmd Process Types
 
 When deploying to Drycc Workflow using a Heroku Buildpack, Workflow boots the `web` process type to
-boot the application server. When you deploy an application that has a Dockerfile or uses [Docker
-images][docker image], Workflow boots the `cmd` process type. Both act similarly in that
+boot the application server. When you deploy an application that has a Dockerfile or uses [Container
+images][container image], Workflow boots the `cmd` process type. Both act similarly in that
 they are exposed to the router as web applications. However, the `cmd` process type is special
 because, if left undefined, it is equivalent to running the [container][] without any additional
-arguments.  (i.e. The process specified by the Dockerfile or Docker image's `CMD` directive will
+arguments.  (i.e. The process specified by the Dockerfile or Container image's `CMD` directive will
 be used.)
 
-If migrating an application from Heroku Buildpacks to a Docker-based deployment, Workflow will not
+If migrating an application from Heroku Buildpacks to a Container-based deployment, Workflow will not
 automatically convert the `web` process type to `cmd`. To do this, you'll have to manually scale
 down the old process type and scale the new process type up.
 
@@ -287,6 +287,6 @@ the Pod to a new node.
 [process model]: https://devcenter.heroku.com/articles/process-model
 [buildpacks]: ../applications/using-buildpacks.md
 [dockerfile]: ../applications/using-dockerfiles.md
-[docker image]: ../applications/using-docker-images.md
+[container image]: ../applications/using-container-images.md
 [HPA]: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
 [autoscale-algo]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/horizontal-pod-autoscaler.md#autoscaling-algorithm

src/applications/using-buildpacks.md

@@ -51,11 +51,11 @@ Use `git push drycc master` to deploy your application.
     ---> Waiting caddy running.
     ---> Process caddy started.
     ---> Building pack
-    ---> Using builder docker.io/drycc/buildpacks:20
-    Builder 'docker.io/drycc/buildpacks:20' is trusted
-    Pulling image 'index.docker.io/drycc/buildpacks:20'
+    ---> Using builder registry.drycc.cc/drycc/buildpacks:bookworm
+    Builder 'registry.drycc.cc/drycc/buildpacks:bookworm' is trusted
+    Pulling image 'registry.drycc.cc/drycc/buildpacks:bookworm'
     Resolving "drycc/buildpacks" using unqualified-search registries (/etc/containers/registries.conf)
-    Trying to pull docker.io/drycc/buildpacks:20...
+    Trying to pull registry.drycc.cc/drycc/buildpacks:bookworm...
     Getting image source signatures
     ...
     ---> Skip generate base layer
@@ -124,7 +124,7 @@ are pushing.
 To use a custom buildpack, you need create a `.pack_builder` file in your root path app.
 
     $  tee > .pack_builder << EOF
-       > docker.io/drycc/buildpacks:20
+       > registry.drycc.cc/drycc/buildpacks:bookworm
        > EOF
 
 On your next `git push`, the custom buildpack will be used.
@@ -144,7 +144,7 @@ key exists in your [GitHub settings][]. Then set `SSH_KEY` to the corresponding
 and set `.pack_builder` to the builder image:
 
     $  tee > .pack_builder << EOF
-       > docker.io/drycc/buildpacks:20
+       > registry.drycc.cc/drycc/buildpacks:bookworm
        > EOF
     $ git add .buildpack
     $ git commit -m "chore(buildpack): modify the pack_builder"

src/applications/using-docker-images.md …c/applications/using-container-images.mdsrc/applications/using-docker-images.md renamed to src/applications/using-container-images.md src/applications/using-docker-images.md renamed to src/applications/using-container-images.md

@@ -1,6 +1,6 @@
 # Using Dockerfiles
 
-Drycc supports deploying applications via Dockerfiles.  A [Dockerfile][] automates the steps for crafting a [Docker Image][].
+Drycc supports deploying applications via Dockerfiles.  A [Dockerfile][] automates the steps for crafting a [Container Image][].
 Dockerfiles are incredibly powerful but require some extra work to define your exact application runtime environment.
 
 ## Add SSH Key
@@ -34,7 +34,7 @@ In order to deploy Dockerfile applications, they must conform to the following r
 * The Dockerfile must use the `EXPOSE` directive to expose exactly one port.
 * That port must be listening for an HTTP connection.
 * The Dockerfile must use the `CMD` directive to define the default process that will run within the container.
-* The Docker image must contain [bash](https://www.gnu.org/software/bash/) to run processes.
+* The Container image must contain [bash](https://www.gnu.org/software/bash/) to run processes.
 
 !!! note
     Note that if you are using a private registry of any kind (`gcr` or other) the application environment must include a `$PORT` config variable that matches the `EXPOSE`'d port, example: `drycc config:set PORT=5000`. See [Configuring Registry](../installing-workflow/configuring-registry/#configuring-off-cluster-private-registry) for more info.
@@ -123,10 +123,10 @@ process type directly changes the number of [containers][container]
 running that process.
 
 
-## Docker Build Arguments
+## Container Build Arguments
 
-As of Workflow v2.13.0, users can inject their application config into the Docker image using
-[Docker build arguments][build-args]. To opt into this, users must add a new environment variable
+As of Workflow v2.13.0, users can inject their application config into the Container image using
+[Container build arguments][build-args]. To opt into this, users must add a new environment variable
 to their application:
 
 ```