Use local CLI for your microservices with Dockerbased stack

Wercker is a Docker-Native CI/CD Automation platform for Kubernetes & Microservice Deployments

Andy Smith
Andy Smith
May 16, 2015

Today we’re releasing four awesome new features that will change the way you develop:

the wercker dev command, the internal/watch step, theinternal/shell step, and the --attach-on-error flag.

Improving local development

Wercker is a great way to build, test and deploy your apps and microservices. Loading services in containers alongside the code that will be using them narrows the delta between development and production, which leads to more robust applications.

With the release of Ewok and the new wercker CLI, we brought that same power to your desktop, giving you the option to run the wercker stack locally and test experimental changes out before you commit (because some code you just know you are going to mess up the first couple times).

local_development_with_wercker

Today we’re taking the next step and giving you the tools to leverage the wercker stack even earlier: while you’re developing. With wercker dev, the watch step, and the shell step you can now run your container and associated services liveagainst your code while you are writing it, especially wonderful for frontend devs. With the --attach-on-error flag you can drop into a shell to inspect the container whenever a step fails, a great tool to speed up your debugging.

Wercker dev

The wercker dev command adds support for an additional pipeline type designed for live development linked to a running environment. When running a normal build pipeline, wercker makes a copy of your code inside the container to prevent side effects affecting your local checkout. Running a dev pipeline does just the opposite and directly mounts your local directory in the container so that changes can be reflected instantly. Combined with internal/watch this lets you do nice things like recompile and run your code after each local change.

internal/watch

The internal/watch step gives you a long-running step that can be configured to reload on file changes. A very common use case for this step is frontend development, here’s an example from our getting-started-nodejs project:

box: nodesource/trusty
dev:
  steps:
    - npm-install
    - internal/watch:
        code: node app.js
        reload: true

With this dev pipeline we run one initial setup step, npm-install, to prepare our container’s environment, then we execute our node app, reloading on changes.

To run this, you would do:

$ wercker dev --publish 5000

And once it loads, browse to your docker host (either localhost on linux, or with boot2docker usually on 192.168.59.103) on port 5000 to see your app running. For your convenience, we’ll tell you the IP once the step runs.

As you make changes to your code, the app will be reloaded, but the npm-install steps will not be run again.

Without the “reload: true” the code will only be run once, which is useful if your development server has its own reloading semantics (or is only loading static files).

internal/shell

The internal/shell step is pretty simple: it drops you into a shell as soon as the step is run.

You can use it much the same way as internal/watch. If you want to run a service, but be able to mess with different flags for testing, just CTRL-C the service and restart it however you want.

You can also use it as a way to inspect the state of the system between steps, drop into a shell, and look around.

Here’s a use case where you’re checking some log entries:

box: nodesource/trusty
dev:
  - npm-install
  - internal/shell:
      cmd: /bin/sh  #defaults to /bin/bash
      code: |
        # some code to automatically run in your shell session
        # before you start interacting
        cd /var/log

–attach-on-error

The --attach-on-error flag can be added to your wercker build runs as well as the new wercker dev command, and its usage is pretty simple: if a step fails, it will re-instantiate the container and drop you into a shell running inside it. This is wonderful for debugging when you have some code in a step that fails in an unexpected way.

Requirements

As with running your build pipelines locally, the wercker dev command requires a working Docker environment such as boot2docker. You can read more about the installation requirements on our dev center.

Get started now

You can download the wercker CLI from the downloads page, or if you already have the wercker CLI installed make sure you use wercker version to get a link to the latest version.

wercker dev in action

Check out the dev section of the wercker.yml files for these sample projects:

Earn some stickers!

Let us know about the applications you build with wercker. Don’t forget to tweet out a screenshot of your first green build with #wercker and we’ll send you some @wercker stickers.

Follow us on twitter as well to stay in the loop.

 

Topics: Product, Containers