Services /

Service Configuration

Service dashboard controls

Each service dashboard has specific controls for the service in the header.

Build latest

You can toggle Build latest on Combined and Build services to enable or disable automatically building the latest commit to the selected branch, or pull request. If you have configured rules on your Build service, only the latest commit matching those criteria will be built.

Deploy latest

You can toggle Deploy latest on Combined services to enable or disable the automatic deployment of new builds. All instances will be redeployed with a new build. If you also have Build latest enabled, your Combined services will automatically build and deploy the latest commit.

Redeploy

You can redeploy Combined and Deployment services to automatically start new instances and halt the instances currently running. New instances will be created before the existing instances are stopped to ensure continuous service.

Scaling

You can scale up or down the amount of instances on Combined and Deployment services to your desired amount by entering the desired amount and saving.

Pause

You can pause a Combined service to disable latest build, deploy latest, and scale all instances to 0.

You can pause a Build service to disable latest build.

You can pause a Deployment service to scale all instances to 0.

Build

You can click the build button on Build services in order to select a branch or pull request to build a commit from.

Environment / configuration

Build Arguments (ARG)

You can set build arguments in Build and Combined services to be passed to the Docker container at build-time. You cannot set build arguments in Deployment services as these services do not build images.

Your build arguments will be passed to the Dockerfile on build via the --build-arg flag. They do not persist in the built image and are set as key-value pairs. Variables must be declared in the Dockerfile with ARG before being accessed. For example, a variable set as "packages" : "npm-cache" can be accessed in the Dockerfile by declaring the ARG:

ARG packages
# or initialise with a default value:
# ARG packages=default_value

RUN echo "Using: ${packages}"

To set Build Arguments:

  1. Select the Configuration tab (Build service) or Environment tab (Combined service)
  2. Open Build arguments and enter your password if prompted
  3. If the toggle is set to view mode, switch to edit mode
  4. Click Add variable and enter the key and value for your new argument
  5. Repeat for as many arguments you require
  6. Click Update arguments to save

You can also enter or edit build arguments using JSON by toggling JSON view on and using the following format:

{
    "key1": "value1",
    "key2": "value2"
}

Learn more about ARG

.

Environment Parameters (ENV)

You can set environment parameters in Deployment and Combined services to be passed to the Docker container at runtime. You cannot set environment parameters in Build services as these services do not have a running container.

Your environment parameters can be accessed via the process environment. They will not, however, be saved in the Container's filesystem.

Environment parameters can be accessed in the Dockerfile by passing the value to the ENV variable as a build argument (ARG):

ENV env_value=${example_value}
 # set env_value to the value
 # of example_value

After this example_value and env_value all return the value Northflank when accessed in the process environment.

In a Node environment a variable set as `"env_value" : "Northflank"` can be accessed within the container by referring to `process.env.env_value`.

To set environment parameters:

  1. Select the Environment tab
  2. Open Environment parameters and enter your password if prompted
  3. If the toggle is set to view mode, switch to edit mode
  4. Click Add variable and enter the key and value for your new argument
  5. Repeat for as many arguments you require
  6. Click Update arguments to save

You can also enter or edit environment parameters using JSON by toggling JSON view on and using the following format:

{
    "key1": "value1",
    "key2": "value2"
}

Learn more about ENV

.

Build options

You can configure build options in Build services. Dockerfile configuration for Combined services is on the Code tab. You cannot configure build options in Deployment services as these services do not build the image.

Build context

You can specify the set of files to be used in the Docker build process by referring to a specific subdirectory relative to the root of your repository. To build all files from the root, use / as the build context, or refer to a subdirectory such as /myfolder or /myfolder/buildhere.

Learn more about Docker contexts

.

Dockerfile location

You can specify the location of the Dockerfile, relative to the root of the repository. For example root: /Dockerfile, or in a subdirectory: /directory/subdirectory/Dockerfile.

Learn more about the Dockerfile

.

Pull request build rules

You can specify rules to determine which pull Requests should be built. By default, it is set to build every pull request. Here are some example build rules:

RegexResult
*Builds every Pull Request
feature/*Builds every pull request starting with feature/
release/*Builds every pull request starting with release/
feature/testBuilds only the branch feature/test

Branch build rules

You can specify rules to determine which branches should be built. By default, it is set to build every branch. Here are some example build rules:

RegexResult
*Builds every branch
feature/*Builds every branch starting with feature/
release/*Builds every branch starting with release/
feature/testBuilds only the branch feature/test

Docker credentials

You can edit the credentials to access a private external registry on Deployment services that use an external image. See external registries for more information.

Networking

You can manage the network connections of your Deployment and Combined services from the Networking tab.

Ports

Click edit at the top-right of the ports list to add or edit ports. If you have multiple instances running, traffic will be automatically load balanced across your instances.

Public and private ports

Toggle the privacy setting to switch between public and private for each port.

Private ports allow containers in the same Project to communicate with each other. You can access the port within the project by using the internal domain name.

Public ports will automatically be assigned a domain name and TLS certificate, or can be accessed with your own custom domain.

Name

You must give each port in your service a unique name. Your port name will be used to create your Northflank generated domain names.

Public Northflank domain names, available online and used to associate with your own domain names, take the format:

[port-name].[service-name].[project-name].[account-name].northflank.app

Private Northflank domain names, to be used internally by other Northflank services, take the format:

[service-name]:[port-number]

Protocol

You can use HTTP, TCP, or UDP protocols for private ports.

Public ports only support HTTP.

Port

You must specify a port to expose in the range 1 to 65535. It should match a port exposed by your container and must be unique in the service.

DNS

You cannot edit the DNS field, but it displays the public domain name (if the port is public) and the internal domain name (for both public and private ports) for external and internal access respectively. Toggle the switch to view public or private names. You can access the port within the project by using the private domain name in the format:

[service-name]:[port-number]

.

Custom domains

If you have a verified domain associated with your account or team, you will be able to associate the port with a domain or subdomain. To associate a domain with a service, add a CNAME entry in your domain DNS settings, setting the target as the provided public DNS entry for the port you wish to use (e.g. port.deploy.service.user.northflank.app). The time it takes to become available depends on the TTL setting in your domain name provider, see domains for more information.

TLS Certificates

When you add a new public port or associate a public port with a verified domain, Northflank will automatically generate and verify DNS entries, generate TLS certificates, and distribute to edge nodes. You can check the status of DNS and TLS generation, abort generation, or regenerate the DNS entries and TLS certificates if required.

Code

The Code tab is available on Build and Combined services and allows you to manage builds from your linked Git repositories.

On Build services the code tab displays a searchable list of Pull Requests and Branches from your linked Git repository. To start a new build:

  1. Select the Pull Request or Branch that contains the commit you want to build.
  2. Find the commit and click the wrench icon to start a new build.

On Combined services the Code tab has three sections:

Commits

View a list of commits from the branch associated with the service (set during service creation). Click the wrench icon to start a new build of that commit, or, if a build is available, deploy the build of that commit by clicking the deploy icon.

Dockerfile

View and edit the Build context and Dockerfile location. You can also edit the Dockerfile contents

, which will push the changes to your Dockerfile to the repository. Be aware this will affect other services using the same repository! It will trigger new builds on all services using the repository that are set to build latest, and it will automatically deploy that build on services that are set to deploy latest as well.

Build hooks

Build hooks notify Northflank when there is a new commit to a branch or pull request. Our GitHub app automatically manages your build hooks for services using a linked GitHub repository. Northflank automatically adds build hooks to GitLab and Bitbucket, you can regenerate these tokens from this tab if you have removed them from your project or repository.

You can view your webhook tokens in a GitLab project by navigating to your project on GitLab, going to settings, and selecting webhooks.

You can view your webhook tokens in a Bitbucket repository by navigating to your repository on Bitbucket, going to repository settings, and selecting webhooks from the workflow section.

Builds

The Builds tab is available on Combined and Build services. Click New build in a Build service in order to select a commit to build.

Select a current or past build to view the logs for that build, you can also retry the build from the logs screen.

The lists display the status of current and past builds. Only the 8 most recent past builds are shown.

Build statuses

  • Pending: the build is queued to start
  • Cloning: the repository is being cloned
  • Building: the build is in progress
  • Uploading: the build was successful and the image is being uploaded to Northflank
  • Aborted: the build was cancelled by the user
  • Failed: the build could not be completed
  • Successful: the build was completed and the image is available on Northflank

Instances

The Instances tab is available on Combined and Deployment services and displays lists of running and terminated instances which can be filtered by state. Only the 10 most recently terminated instances are displayed.

Instance statuses

  • Staging: the container is scheduled for deployment
  • Starting: the container is being deployed
  • Running: the container is running
  • Killing: the container is scheduled to terminate
  • Killed: the container has been terminated

Scaling

The scaling tab is available on all services.

In Build services you can update the Plan to allocate more resources to the service.

In Deployment and Combined services you can update the Plan to allocate more resources to the service, scale the number of active instances, and toggle between free or paid plans (if you have a free plan available).

Billing

In all services you can view the current usage costs accrued by your service and the invoices from previous months.

Deleting

You can delete a service from the billing page. This will immediately remove the service from any Pipelines it is used in, and remove it from any other associated services.

Deleting a Deployment Service will remove (but not delete) any associated Build Service.

You will still be billed for all usage to date.

© 2020 Northflank Ltd. All rights reserved.

TermsPrivacy

contact@northflank.com