The Kubernetes platform.
The Package manager.
The Open Service Broker.
Drycc workflow requires a wildcard DNS record to dynamically map app names to the router.
User should already have DNS set up pointing to their known host. The
$hostname value can be calculated by prepending
drycc. to the value set in
Workflow use the passport component to create and authorize users.
If you already have an account, use
drycc login to authenticate against the Drycc Workflow API.
$ drycc login http://drycc.example.com 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
Drycc Workflow supports three different types of applications, Buildpacks, Dockerfiles and Container Images. Our first application will be a simple Container Image-based application, so you don't have to wrestle with checking out code.
drycc create to create a new application on Drycc Workflow. If you do not
specify a name for your application, Workflow automatically generates a
friendly (and sometimes funny) name.
$ drycc create --no-remote Creating Application... done, created proper-barbecue If you want to add a git remote for this app later, use `drycc git:remote -a proper-barbecue`
Our application has been created and named
proper-barbecue. As with the
drycc hostname, any HTTP traffic to
proper-barbecue will be automatically
routed to your application pods by the edge router.
Let's use the CLI to tell the platform to deploy an application and then use curl to send a request to the app:
$ drycc pull drycc/example-go -a proper-barbecue Creating build... done $ curl http://proper-barbecue.$hostname Powered by Drycc
If you see a 404 error, make sure you specified your application name with
Workflow's edge router knows all about application names and automatically
sends traffic to the right application. The router sends traffic for
proper-barbecue.22.214.171.124.nip.io to your app, just like
drycc.126.96.36.199.nip.io was sent to the Workflow API service.
Next, let's change some configuration using the CLI. Our example app is built
to read configuration from the environment. By using
drycc config:set we can
change how the application behaves:
$ drycc config:set POWERED_BY="Container Images + Kubernetes" -a proper-barbecue Creating config... done === proper-barbecue Config POWERED_BY Container Images + Kubernetes
Behind the scenes, Workflow creates a new release for your application and uses Kubernetes to provide a zero-downtime rolling deploy to the new release!
Validate that our configuration change has worked:
$ curl http://proper-barbecue.188.8.131.52.nip.io Powered by Container Images + Kubernetes
Last, let's scale our application by adding more application processes. Using the CLI you can easily add and remove additional processes to service requests:
$ drycc scale cmd=2 -a proper-barbecue Scaling processes... but first, coffee! done in 36s === proper-barbecue Processes --- cmd (started): 2 proper-barbecue-v18-cmd-rk644 up (v18) proper-barbecue-v18-cmd-0ag04 up (v18)
Congratulations! You have deployed, configured, and scaled your first application using Drycc Workflow.
There is a lot more you can do with Drycc Workflow, play around with the CLI:
drycc rollback -a proper-barbecue
drycc logs -a proper-barbecue