The classic Wercker stack uses LXC containers as the underlying image format. The Workflows stack is based on Docker containers and is the most current one. It enables developers to use any Docker container from any registry and create any number of pipelines. The Workflows stack comes with a new Command Line Interface (CLI) that allows you to run pipelines locally on your machine.
This article serves as a guide to migrate your existing classic application to the Workflows stack.
Table of Contents
- Introducing the Workflows stack
- The migration process
- Moving from official Wercker boxes to Docker
- Third-party Android container
- Moving from official Wercker services to Docker
- Using Steps
- How to deploy to Heroku
The Workflows stack is based on the Docker container format. Docker is a popular format for packaging up your applications and running them on schedulers such as Kubernetes. Though Wercker plays extremely nicely with Docker, you are not obligated to do anything with your built containers on the Workflows stack.
Beyond using Docker as the container runtime, the Workflows stack enables you to create any number of pipelines, allowing you to go beyond`build` and `deploy`. Pipelines can be chained and run on completion of previous pipelines. You can even branch your pipelines, thus creating complex Workflows for your automation needs. Finally, the Workflows stack comes with a powerful CLI allowing you to run pipelines locally, enabling a fast feedback loop and iteration on your application before pushing to the Wercker Cloud.
There are two ways to migrate your application to the Workflows stack:
Migrate your application via the migration wizard and update your wercker.yml as directed here.
Delete your application on Wercker and start anew. New applications are Workflows-based by default.
Because the Workflows stack uses Docker containers as the underlying environment to run your pipeline jobs, you can use any container from Docker Hub or other container registries, like Quay and GCR.
This means there is no longer a need for Wercker to use officially supported containers. Below you can find a list of official LXC containers previously available on the classic stack, with some recommendations to equivalent Docker containers.
Note that if you can't find what you're looking for, you can always create your own container.
Wercker classic had officially supported LXC containers for the following programming environments; these are sensible defaults for their Docker counterparts.
In the yaml file itself, you still use the
box clause to define your container as you would otherwise. Official containers from the Docker Hub do not need a prefix.
For example, if you want to use the above-mentioned Python container, you would define this as:
See this article for more information on using containers.
In a fashion similar to the language containers mentioned above, you can use any Docker container for your services, such as a database or queue. As with the classic stack, services are spun up next to the main programming environment container. Below you can find a list of official LXC containers previously available on the classic stack, with some recommendations on their Docker equivalents.
Wercker classic had officially supported LXC containers for the following services:
See this article on how to connect to your service containers from within your main container.
You can still use the steps from the Wercker Step registry as you did before. Remember however that some steps might require certain language dependencies to be present, which might no be the case for your Docker container. (For instance, Python might not be installed, whereas the step uses Python to function.)
We no longer support Heroku deploy targets. Instead, you can use the Heroku Deploy step inside of your wercker.yml.