Interface is designed to be as simple as possible. The main principle is based on a 2-collumn layout with main menu on top, a list of available items on the left, and an item overview on the right.
Account section: this section contains information about the account or organization you are logged into. Here you add or remove your organization, manage access for your teammates, can find personal or organization profile, personal settings and billing information. Access your account or Organization info by clicking your avatar.
The Main menu is the main navigation point for key actions. Here you can easily access your workspaces or repositories, access connected cluster or registries. We organize our header into three sections: deployment in workspace section, builds in repositories section, infrastructure management in the same name section.
Infrastructure section stores connected open-source orchestration clusters and open-source build registries. You can create, add or remove orchestration clusters in cluster section. Registries manage functional is located in registry section.
Workspace section and Catalog is the core point of your applications management. After you select workspace, you’ll see its components like services, volumes, routes, etc.. Run new application in service page, create or attach persistent storage in storage section.
Repositories section is all about build and store container images. Build images from connected source code repo, search already built public container images in catalog section.
Workspaces and repositories are the most fundamental building blocks of your infrastructure. Next we’ll show you how to create and manage them.
Interface orchestration cluster
Orchestration cluster is a cluster of virtual or physical resources (nodes), where you can run and manage your applications or organize storage. Cluster contains master nodes for managing infrastructure state and minion nodes - where your apps are running.
You can create a new cluster in a few different ways:
- Obtain it in an automatic way by using the interface
- Create by yourself using your own resources in a preferred hosting or cloud provider
How to deploy last backend cluster by yourself you can read in our documentation, located here. After you have the orchestration cluster, you will need to connect it to our control system.
How to connect cluster
Orchestration cluster is a powerful system by itself, but when it is connected to our control system it transforms into a supercharged cluster with automation triggers, monitoring and other cool features.
To connect your cluster, just fill in it’s name, description (optional), access endpoint and access token. Provided that you have already secured your cluster with ssl certificates, you have to upload them and check TLS checkbox. That’s all.
After a few seconds, you’ll be ready to deploy your apps.
After cluster is connected, you’ll be redirected to cluster page, where you can see cluster state, resources, connected nodes, ingress and discovery servers. On that page you can make cluster changes, like selection labels, notifications or sharing access control settings.
Create your first workspace
Workspace is where your apps live. Workspaces are based on namespaces, with custom quotas, access rules and domain names. The main purpose of workspace is to separate projects and project stages. Each workspace can be scheduled to different clusters and different nodes in the cluster, by special selectors. You can set workspace resources quotas and access rules for teammates.
How to create new workspace
To create new workspace - just go to workspaces list and click “add new” button. You’ll see new workspace form, where you’ll need to fill:
- Workspace unique name in cluster
- Workspace description (optional)
- Select connected orchestration cluster
- Workspace domain name (optional)
- Setup quotas if needed
After you click Create button, control system will create a new namespace in the orchestration cluster you’ve selected.
Deploy your first service
Now that you have a workspace, we’ll walk you through how to deploy your first application. Lets try this with our favorite example: the popular blog platform Ghost. Each application contains a set of components: service, route, storage and config. In this section we’ll start with the core of each application - service.
We use containers to run applications, so service is a set of containers with a specific configuration. Each service has a particular running version (deployment) which allows you to not worry about updates and rollbacks. You can see full service for documentation, design principles, and available configuration in our doc: here.
You can create service in 2 ways:
- Fill the form
- Write or upload .yml file
For this guide, we have prepared .yml file for our example app: This file is located in github here
To deploy this service, go-to create new service page, switch selector to yaml and upload file.
After you click Create button, you’ll be redirected to created service overview page, where you’ll see service deployment status. Wait for a minute for successful deployment, and then on to the next step After service is ready, it will be indicated as ready.
This page is a control point for your service:
Overview section displays service information like: current deployment, provision deployments, deployment configuration, network settings and current state.
Configuration section is a place where you can change service configuration, from container image, runtime options, environment variables to network settings and other.
Logs tab allows you to see containers realtime log output. It’s very helpful if you need to understand what is going on and to debug current deployment.
Triggers section provides additional automation, like auto-deploy after a new version of container image is available or other types of triggers.
Monitoring section will show you metrics and graphs of resources usage for now. In the future we’re planning to focus more on this section to create custom metrics collector.
Events list displays all events about this service, from successful or failed deployments to container statuses events.
Settings tab is a place, where you can create custom notifications for service, remove it or set service in maintenance mode.
Make service available from internet
Now you have the running service in your cluster. Each service is working in the internal network and if you need to provide external access to it, you’ll need to create an external traffic route (just route). There is a special section in sidebar. Go to routes and click “create new route”.
There is a simple form:
- Unique route name in the workspace. This name will be used as subdomain as entrypoint.
- Route rules are traffic management rules.
Note: You can set different service and ports for different endpoint locations. For example you can send traffic from / location to one service and traffic from /demo location to another service.
Fill in these values for example:
- Name: blog
- Rule 1: service: ghost, port: 80->2368
After clicking Create button, a new route will be provisioned in the ingress server and you can access our example app from browser:
Yay! Congrats, your first example service is successfully deployed and you can spend a few minutes playing it. For more complex applications with persistent storages or config files, go to the fully described guide in our docs.
Build from source code
We’ve deployed the example service. Great! What about deploying from source code. For this case we need to connect the container images registry. This is an open-source system for building container images from source code, located in github, bitbucket or gitlab. Registry contains master nodes for manage builds and control build workers, minion nodes for build processes execution.
You can use Last.Backend container images registry as a starting point, also you can connect your own container images registry at any time.
You can create new registry in few different ways:
- Obtain it in an automatic way by using the interface
- Create by yourself using your own resources in preferred hosting or cloud provider
How to deploy last.backend registry by yourself? You can find more detail in our documentation, located here. After you have registry, you will need connect it to our control system.
How to connect registry
Last.Backend container images registry is an automated build system and when it is connected to our control system, these features are automatically accessible:
- Automated builds from popular VSC (github, bitbucket, gitlab)
- Access control list for images sharing
- Custom build rules, like build multiple images from one repository
- Add public repository to Last.Backend catalog
- Deployment templates system for rapid deployment
Registries connect process are the same as orchestration cluster connect:
Here is simple form:
- Registry name
- Registry description (optional)
- Registry endpoint (IP or Domain) of registry API
- Registry hub - domain name for images registry
- Registry access token
If you have secured your regisitry with ssl certificates, you have to upload them and check TLS checkbox. That’s all. After a few seconds, you’ll be ready to build your source into container images.
Add your first repository
To connect your repositories, you need to select your VCS provider and complete authentication. After this step you just need to select it, select your account if you have multiple accounts and start typing the repository name in search box.
By clicking select button you’ll see the form below. Here you can choose the type of repository: private or public. Note that public repos will be automatically accessible for other users in repos catalog. Provide a simple description of your repo in the description box and that’s all.
Now you need to create build rules. These rules describe the build process. You need to select trigger options - when registry will create a new build.
There are 2 triggers provided by default:
- Create container image after commiting in any branch or after new tag is created
- Create container image after commiting only if branch or tag matches specific value
After selecting needed trigger, you need to select or create container image, which will be created or updated after successful build and some build options.
Now, you’ve added build trigger - you can run it in builds section in repository overview page. Here you can see build list with build statuses and logs.
Due to the fact that the build process can take a long time, for your convenience notifications system. You can use 2 types of builds notification:
- Email notification
- Slack notification
Let’s add new slack notification:
Go to settings tab and click create notification. There are 4 types of notification events for now:
- Notify of any build status (default) - system will send notification after build complete in any status
- Notify after build is successful
- Notify after build is canceled
- Notify only if build failed
You can create as many notification triggers as you need. For example, you can send an error build notification in Slack in one channel and a successful build in another. After you have successfully built your container image, you can deploy it in the same way as the example app we’ve deployed earlier. For a fully-detailed guide, go to our documentation.
If you have any questions, we are always happy to assist by way of our communication channels: gitter, Slack, telegram or by email.
Our team is always happy to receive feedback and fresh ideas. We hope we’ll be able to help you implement your ideas and execute common tasks with our system. So, good luck and have fun!
With all the best, your Last.Backend team.