chore(docs): update docs

Author: lijianguo

README.md

@@ -2,9 +2,9 @@
 
 **Drycc Workflow** is an open source Platform as a Service (PaaS) that adds a developer-friendly layer to any [Kubernetes][k8s-home] cluster, making it easy to deploy and manage applications.
 
-To **get started** with **Drycc Workflow** please read the [Quick Start Guide](https://drycc.cc/docs/workflow/quickstart/).
+To **get started** with **Drycc Workflow** please read the [Quick Start Guide](https://drycc.cc/quickstart/).
 
-Visit [https://drycc.cc](https://drycc.cc) for more information on [why you should use Drycc Workflow](https://drycc.cc/why-drycc/) or [learn about its features](https://drycc.cc/how-it-works/).
+Visit [https://drycc.cc](https://drycc.cc) for more information on [why you should use Drycc Workflow](https://drycc.cc/understanding-workflow/concepts/) or [learn about its features](https://drycc.cc/understanding-workflow/architecture/).
 
 This repository contains the source code for Drycc Workflow documentation. If you're looking for individual components, they live in their own repositories.
 
@@ -13,9 +13,7 @@ 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/) based applications
-- [slugbuilder](https://github.com/drycc/slugbuilder) - The builder for [slug/buildpack](https://devcenter.heroku.com/articles/slug-compiler) based applications
-- [slugrunner](https://github.com/drycc/slugrunner) - The runner for slug/buildpack based applications
+- [imagebuilder](https://github.com/drycc/imagebuilder) - The builder for [Docker](https://www.docker.com/) and [CNCF Buildpacks](https://buildpacks.io/) based applications
 - [fluentd](https://github.com/drycc/fluentd) - 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
@@ -31,14 +29,13 @@ We welcome your input! If you have feedback, please [submit an issue][issues]. I
 
 # Working on Documentation
 [![Build Status](https://drone.drycc.cc/api/badges/drycc/workflow/status.svg)](https://drone.drycc.cc/drycc/workflow)
-[![Latest Docs](http://img.shields.io/badge/docs-latest-fc1e5e.svg)](http://docs-v2.readthedocs.org/en/latest/)
 
 The Drycc project welcomes contributions from all developers. The high level process for development matches many other open source projects. See below for an outline.
 
 * Fork this repository.
 * Make your changes.
 * [Submit a pull request][prs] (PR) to this repository with your changes, and unit tests whenever possible.
-	* If your PR fixes any [issues][issues], make sure you write `Fixes #1234` in your PR description (where `#1234` is the number of the issue you're closing).
+    * If your PR fixes any [issues][issues], make sure you write `Fixes #1234` in your PR description (where `#1234` is the number of the issue you're closing).
 * The Drycc core contributors will review your code. After each of them sign off on your code, they'll label your PR with `LGTM1` and `LGTM2` (respectively). Once that happens, a contributor will merge it.
 
 ## Requirements

mkdocs.yml

@@ -48,7 +48,6 @@ nav:
     - Platform Monitoring: managing-workflow/platform-monitoring.md
     - Production Deployments: managing-workflow/production-deployments.md
     - Upgrading Workflow: managing-workflow/upgrading-workflow.md
-    - Extending Workflow: managing-workflow/extending-workflow.md
   - Troubleshooting:
     - Troubleshooting Workflow: troubleshooting/index.md
     - Troubleshooting using Kubectl: troubleshooting/kubectl.md

src/applications/deploying-apps.md

@@ -23,9 +23,9 @@ using the URL supplied by their Drycc administrator.
 
 ```
 $ drycc login http://drycc.example.com
-username: drycc
-password:
-Logged in as drycc
+Opening browser to http://drycc.example.com/v2/login/drycc/?key=4ccc81ee2dce4349ad5261ceffe72c71
+Waiting for login... .o.Logged in as admin
+Configuration file written to /root/.drycc/client.json
 ```
 
 ## Select a Build Process
@@ -34,7 +34,7 @@ Drycc Workflow supports three different ways of building applications:
 
 ### Buildpacks
 
-Heroku buildpacks are useful if you want to follow Heroku's best practices for building applications or if you are porting an application from Heroku.
+Cloud Native Buildpacks are useful if you want to follow [cnb's docs](https://buildpacks.io/docs/) for building applications.
 
 Learn how to deploy applications [using Buildpacks](../applications/using-buildpacks.md).
 
@@ -60,9 +60,9 @@ It is possible to configure a few of the [globally tunable](../applications/mana
 
 Setting                                         | Description
 ----------------------------------------------- | ---------------------------------
-DRYCC_DISABLE_CACHE                              | if set, this will disable the [slugbuilder cache][] (default: not set)
-DRYCC_DEPLOY_BATCHES                             | the number of pods to bring up and take down sequentially during a scale (default: number of available nodes)
-DRYCC_DEPLOY_TIMEOUT                             | deploy timeout in seconds per deploy batch (default: 120)
+DRYCC_DISABLE_CACHE                             | if set, this will disable the [slugbuilder cache][] (default: not set)
+DRYCC_DEPLOY_BATCHES                            | the number of pods to bring up and take down sequentially during a scale (default: number of available nodes)
+DRYCC_DEPLOY_TIMEOUT                            | deploy timeout in seconds per deploy batch (default: 120)
 IMAGE_PULL_POLICY                               | the kubernetes [image pull policy][pull-policy] for application images (default: "IfNotPresent") (allowed values: "Always", "IfNotPresent")
 KUBERNETES_DEPLOYMENTS_REVISION_HISTORY_LIMIT   | how many [revisions][kubernetes-deployment-revision] Kubernetes keeps around of a given Deployment (default: all revisions)
 KUBERNETES_POD_TERMINATION_GRACE_PERIOD_SECONDS | how many seconds kubernetes waits for a pod to finish work after a SIGTERM before sending SIGKILL (default: 30)

src/applications/managing-app-configuration.md

@@ -53,11 +53,10 @@ the application to an external PostgreSQL database.
 Detachments can be performed with `drycc config:unset`.
 
 
-## Slugbuilder Cache
+## Buildpacks Cache
 
-By default, apps using the [Slugbuilder][] will have caching turned on. This means that Drycc will
-persist all data being written to `CACHE_DIR` inside the buildpack will be persisted between
-deploys. When deploying applications that depend on third-party libraries that have to be fetched,
+By default, apps using the [Imagebuilder][] will reuse the latest image data.
+When deploying applications that depend on third-party libraries that have to be fetched,
 this could speed up deployments a lot. In order to make use of this, the buildpack must implement
 the cache by writing to the cache directory. Most buildpacks already implement this, but when using
 custom buildpacks, it might need to be changed to make full use of the cache.

src/applications/using-buildpacks.md

@@ -1,6 +1,6 @@
 # Using Buildpacks
 
-Drycc supports deploying applications via [Heroku Buildpacks][]. Buildpacks are useful if you're interested in following Heroku's best practices for building applications or if you are deploying an application that already runs on Heroku.
+Drycc supports deploying applications via [Cloud Native Buildpacks](https://buildpacks.io/). Cloud Native Buildpacks are useful if you want to follow [cnb's docs](https://buildpacks.io/docs/) for building applications.
 
 ## Add SSH Key
 
@@ -44,18 +44,43 @@ Use `git push drycc master` to deploy your application.
     Compressing objects: 100% (48/48), done.
     Writing objects: 100% (75/75), 18.28 KiB | 0 bytes/s, done.
     Total 75 (delta 30), reused 58 (delta 22)
+    remote: --->
     Starting build... but first, coffee!
-    -----> Go app detected
-    -----> Checking Godeps/Godeps.json file.
-    -----> Installing go1.4.2... done
-    -----> Running: godep go install -tags heroku ./...
-    -----> Discovering process types
-           Procfile declares types -> web
-    -----> Compiled slug size is 1.7M
+    ---> Waiting podman running.
+    ---> Process podman started.
+    ---> 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'
+    Resolving "drycc/buildpacks" using unqualified-search registries (/etc/containers/registries.conf)
+    Trying to pull docker.io/drycc/buildpacks:20...
+    Getting image source signatures
+    ...
+    ---> Skip generate base layer
+    ---> Python Buildpack
+    ---> Downloading and extracting Python 3.10.0
+    ---> Installing requirements with pip
+    Collecting Django==3.2.8
+    Downloading Django-3.2.8-py3-none-any.whl (7.9 MB)
+    Collecting gunicorn==20.1.0
+    Downloading gunicorn-20.1.0-py3-none-any.whl (79 kB)
+    Collecting sqlparse>=0.2.2
+    Downloading sqlparse-0.4.2-py3-none-any.whl (42 kB)
+    Collecting pytz
+    Downloading pytz-2021.3-py2.py3-none-any.whl (503 kB)
+    Collecting asgiref<4,>=3.3.2
+    Downloading asgiref-3.4.1-py3-none-any.whl (25 kB)
+    Requirement already satisfied: setuptools>=3.0 in /layers/drycc_python/python/lib/python3.10/site-packages (from gunicorn==20.1.0->-r requirements.txt (line 2)) (57.5.0)
+    Installing collected packages: sqlparse, pytz, asgiref, gunicorn, Django
+    Successfully installed Django-3.2.8 asgiref-3.4.1 gunicorn-20.1.0 pytz-2021.3 sqlparse-0.4.2
+    ---> Generate Launcher
+    ...
     Build complete.
-    Launching app.
-    Launching...
-    Done, skiing-keypunch:v2 deployed to Drycc
+    Launching App...
+    ...
+    Done, skiing-keypunch:v2 deployed to Workflow
 
     Use 'drycc open' to view this application in your browser
 
@@ -68,7 +93,7 @@ Use `git push drycc master` to deploy your application.
     Powered by Drycc
     Release v2 on skiing-keypunch-v2-web-02zb9
 
-Because a Heroku-style application is detected, the `web` process type is automatically scaled to 1 on first deploy.
+Because a Buildpacks-style application is detected, the `web` process type is automatically scaled to 1 on first deploy.
 
 Use `drycc scale web=3` to increase `web` processes to 3, for example. Scaling a
 process type directly changes the number of [pods] running that process.
@@ -78,18 +103,13 @@ process type directly changes the number of [pods] running that process.
 
 For convenience, a number of buildpacks come bundled with Drycc:
 
- * [Ruby Buildpack][]
- * [Nodejs Buildpack][]
+ * [Go Buildpack][]
  * [Java Buildpack][]
- * [Gradle Buildpack][]
- * [Grails Buildpack][]
- * [Play Buildpack][]
- * [Python Buildpack][]
+ * [Nodejs Buildpack][]
  * [PHP Buildpack][]
- * [Clojure Buildpack][]
- * [Scala Buildpack][]
- * [Go Buildpack][]
- * [Multi Buildpack][]
+ * [Python Buildpack][]
+ * [Ruby Buildpack][]
+ * [Rust Buildpack][]
 
 Drycc will cycle through the `bin/detect` script of each buildpack to match the code you
 are pushing.
@@ -101,32 +121,14 @@ are pushing.
 
 ## Using a Custom Buildpack
 
-To use a custom buildpack, you need create a `.buildpack` file in your root path app.
+To use a custom buildpack, you need create a `.pack_builder` file in your root path app.
 
-    $  tee > .buildpack << EOF
-       > https://github.com/dpiddy/heroku-buildpack-ruby-minimal
+    $  tee > .pack_builder << EOF
+       > docker.io/drycc/buildpacks:20
        > EOF
 
-!!! note
-    If, however, you're unable to deploy using the latest version of the buildpack, You can set an exact version of a buildpack by using a git revision in your `.buildpack`. For example: `https://github.com/dpiddy/heroku-buildpack-ruby-minimal#v13`
-
 On your next `git push`, the custom buildpack will be used.
 
-
-## Compile Hooks
-
-Sometimes, an application needs a way to stop or check if a service is running before building an
-app, which may require notifying a service that the [Builder][] has finished compiling the app. In
-order to do this, an app can provide two files in their `bin/` directory:
-
-```
-bin/pre-compile
-bin/post-compile
-```
-
-The builder will run these commands before and after the build process, respectively.
-
-
 ## Using Private Repositories
 
 To pull code from private repositories, set the `SSH_KEY` environment variable to a private key
@@ -139,39 +141,34 @@ which has access. Use either the path of a private key file or the raw key mater
 
 For example, to use a custom buildpack hosted at a private GitHub URL, ensure that an SSH public
 key exists in your [GitHub settings][]. Then set `SSH_KEY` to the corresponding SSH private key
-and set `.buildpack` to the URL:
+and set `.pack_builder` to the builder image:
 
-    $  tee > .buildpack << EOF
-       > https://github.com/dpiddy/heroku-buildpack-ruby-minimal
+    $  tee > .pack_builder << EOF
+       > docker.io/drycc/buildpacks:20
        > EOF
     $ git add .buildpack
-    $ git commit -m "chore(buildpack): modify the buildpack url"
+    $ git commit -m "chore(buildpack): modify the pack_builder"
     $ git push drycc master
 
 ## Builder selector
 
 Which way to build a project conforms to the following principles:
 
 - If Dockerfile exists in the project, the stack uses `container`
-- If Procfile exists in the project, the stack uses `heroku-18`
+- If Procfile exists in the project, the stack uses `buildpack`
 - If both exist, `container` is used by default
-- You can also set the `DRYCC_STACK` to determine which stack to use.
+- You can also set the `DRYCC_STACK` to `container` or `buildpack` determine which stack to use.
 
 
 [pods]: http://kubernetes.io/v1.1/docs/user-guide/pods.html
 [controller]: ../understanding-workflow/components.md#controller
 [builder]: ../understanding-workflow/components.md#builder
-[Ruby Buildpack]: https://github.com/heroku/heroku-buildpack-ruby
-[Nodejs Buildpack]: https://github.com/heroku/heroku-buildpack-nodejs
-[Java Buildpack]: https://github.com/heroku/heroku-buildpack-java
-[Gradle Buildpack]: https://github.com/heroku/heroku-buildpack-gradle
-[Grails Buildpack]: https://github.com/heroku/heroku-buildpack-grails
-[Play Buildpack]: https://github.com/heroku/heroku-buildpack-play
-[Python Buildpack]: https://github.com/heroku/heroku-buildpack-python
-[PHP Buildpack]: https://github.com/heroku/heroku-buildpack-php
-[Clojure Buildpack]: https://github.com/heroku/heroku-buildpack-clojure
-[Scala Buildpack]: https://github.com/heroku/heroku-buildpack-scala
-[Go Buildpack]: https://github.com/kr/heroku-buildpack-go
-[Multi Buildpack]: https://github.com/heroku/heroku-buildpack-multi
-[Heroku Buildpacks]: https://devcenter.heroku.com/articles/buildpacks
+[Go Buildpack]: https://github.com/drycc/pack-images/tree/main/buildpacks/go
+[Java Buildpack]: https://github.com/drycc/pack-images/tree/main/buildpacks/java
+[Nodejs Buildpack]: https://github.com/drycc/pack-images/tree/main/buildpacks/nodejs
+[PHP Buildpack]: https://github.com/drycc/pack-images/tree/main/buildpacks/php
+[Python Buildpack]: https://github.com/drycc/pack-images/tree/main/buildpacks/python
+[Ruby Buildpack]: https://github.com/drycc/pack-images/tree/main/buildpacks/ruby
+[Rust Buildpack]: https://github.com/drycc/pack-images/tree/main/buildpacks/rust
+[Cloud Native Buildpacks]: https://buildpacks.io/
 [GitHub settings]: https://github.com/settings/ssh

src/installing-workflow/configuring-object-storage.md

@@ -44,7 +44,7 @@ Operators should configure object storage by editing the Helm values file before
 	All values will be automatically (base64) encoded _except_ the `key_json` values under `gcs`/`gcr`.  These must be base64-encoded.  This is to support cleanly passing said encoded text via `helm --set` cli functionality rather than attempting to pass the raw JSON data.  For example:
 
 		$ helm install workflow --namespace drycc \
-                        --set global.platform_domain=youdomain.com
+			--set global.platform_domain=youdomain.com
 			--set global.storage=gcs,gcs.key_json="$(cat /path/to/gcs_creds.json | base64 -w 0)"
 
 You are now ready to run `helm install drycc/workflow --namespace drycc -f values.yaml` using your desired object storage.

src/installing-workflow/configuring-postgres.md

@@ -1,6 +1,6 @@
 # Configuring Postgres
 
-Drycc Workflow's controller component relies on a PostgreSQL database to store platform state.
+Drycc Workflow's controller and passport component rely on a PostgreSQL database to store platform state.
 
 By default, Drycc Workflow ships with the [database] component, which provides an in-cluster PostgreSQL database backed up to in-cluster or off-cluster [object storage]. Currently, for object storage, which is utilized by _several_ Workflow components, only off-cluster solutions such as S3 or GCS are recommended in production environments. Experience has shown that many operators already opting for off-cluster object storage similarly prefer to host Postgres off-cluster as well, using Amazon RDS or similar. When excercising both options, a Workflow installation becomes entirely stateless, and is thus restored or rebuilt with greater ease should the need ever arise.
 

src/installing-workflow/index.md

@@ -74,10 +74,8 @@ If you want to change it, set the variable when using helm.
 ```
 $ helm install --namespace drycc \
     --set builder.image_registry=quay.io \
-    --set slugbuilder.image_registry=quay.io \
     --set imagebuilder.image_registry=quay.io \
     --set controller.image_registry=quay.io \
-    --set slugrunner.image_registry=quay.io \
     --set database.image_registry=quay.io \
     --set fluentd.image_registry=quay.io \
     --set redis.image_registry=quay.io \
@@ -163,5 +161,5 @@ Once all of the pods are in the `READY` state, and `drycc-builder.$host` resolve
 
 After installing Workflow, [register a user and deploy an application](../quickstart/deploy-an-app.md).
 
-If your k8s does not provide public network loadblance, you need to install TCP proxy services such as haproxy on machines that can 
-access both internal and external networks, and then expose `80` and `443`.
+If your k8s does not provide public network loadblance, you need to install TCP proxy services such as haproxy on machines that can
+access both internal and external networks, and then expose `80` and `443`.