Introducing Acorn Services and Nested Acorns

Applications today are typically a composition of microservices, storage, databases, and APIs. Describing an application’s runtime dependencies typically involves infrastructure provisioning like Terraform and/or complex YAML. In Acorn 0.7, which we released today, we are introducing two powerful new concepts, services and nested Acorns to simplify describing applications for developers. Services provide an Acorn native way for a developer to provision and consume cloud resources. While nested Acorns provide a way to describe and build delivery pipelines for each phase of an application’s lifecycle.

Acorn Services

Acorn Services offer a flexible plugin framework that simplifies the app description and provisioning process of 3rd party components for developers. Service Acorns can leverage existing tools like CloudFormation or Terraform to provision database, message queues, or object storage from a cloud provider. By using services, developers can describe their application deployments and swap out the service implementations without having to change the Acorn app description.

When the operations team creates a service Acorn for their developers, it is simple for the developers to consume. Lets look at an example Acornfile that consumes a Redis database from a service Acorn.

services: redis: {
    build: {
        context: "."
    }
}

containers: "redis-cli": {
    image: "redis:alpine"
    entrypoint: ["sleep"]
    command: ["3600"]
    env: {
        REDIS_HOST: "@{service.redis.address}"
        REDIS_PORT: "@{service.redis.port.6379}"
        REDISCLI_AUTH: "@{service.redis.secrets.redis-password.token}"
        REDIS_TLS_REQUIRED: "@{service.redis.data.tls}"
    }
}

When deployed, the Redis service will be created on Aiven cloud, and the address and credentials fed into the redis-cli container. The redis-cli container will then be able to connect to the redis service using the credentials provided.

You can find the full example code here.

For more information on consuming Acorn services, check out the docs. To learn how to create new services for your team, take a look at this section in the docs.

Nested Acorns

Modern best practices tell us you should have a complete definition of your application deployments and be able to check that in to source control so that it can be versioned and audited. By taking advantage of profiles and nested Acorns you can now define your applications, services and default values for deployments in dev, test, and production in a single Acornfile. Also, taking advantage of Acorn’s auto-upgrade feature, you can ensure that all of your deployments are always up to date with the latest version of your application.

Let’s say we have a simple Python Flask app:

import os 

from flask import Flask

app = Flask(__name__)

@app.route('/')
def index():
    env=os.getenv("ENV", "dev")
    return "<h1>Hello World!</h1><p>env: " + env + "</p>"

app.run(host='0.0.0.0', port=5000, debug=True)

containerized with the following Dockerfile:

FROM python:alpine

ADD . /app
WORKDIR /app
RUN pip install -r requirements.txt
ENTRYPOINT [ "python" ]
CMD [ "app.py" ]

We can create a simple Acornfile to run and deploy this application:

args: {
  env: "dev"
}

containers: app: {
  build: context: "."
  env: {
    ENV: "\(args.env)"
  }
  ports: publish: "5000/http"
}

The above Acornfile contains everything needed to deploy this simple application. Now lets say we want to deploy this application to dev, test, and production environments. Before nested Acorns, we would have to run acorn run acorn-app --env test and acorn run acorn-app --env prod for each environment. With only a few obvious arguments this isn’t a big deal, but as the number of arguments and environments grow, this can become a maintenance headache. With nested Acorns we can create a single Acornfile that defines the application and the environments.

args: {
    env: "test"
    tag: "latest"
}

profiles: {
    "prod": {
        env: "prod"
        tag: "prod"
    }
}

acorns: app: {
    image: "index.docker.io/cloudnautique/deploy-acorn-app:\(args.tag)"
    deployArgs: env: "\(args.env)"
    autoUpgrade: true
    autoUpgradeInterval: "1m"
    publishMode: "defined"
}

When this Acornfile is applied to each environment the app will automatically upgrade to the latest version of the image based on tag. This allows you to define your application across all environments and have a single source of truth that can be checked into source control.

For more information on nested Acorns, check out the docs.

Next Steps

Services and nested Acorns are powerful new features that simplify the process of describing and deploying for developers building applications. With services, developers can describe and deploy infrastructure resources to support the applications. We can now define delivery pipelines using nested Acorns to ensure that there is a single source of truth for all environments. These features are available in the new v0.7.0 release of Acorn, try them out today!