DEV Community: Rémy Apfelbacher

How we setup self-hosted wiki called Outline in Zerops

Rémy Apfelbacher — Mon, 07 Nov 2022 16:23:43 +0000

As our code base grew there was an urgent need for a place where we could gather our knowledge about the system. There are complicated processes in Zerops and not everyone has the right information to carry them out.

We already had a wiki on Redmine, but we wanted something more modern, with good support for editing and markdown out of the box. After some research we ended up choosing Outline, partly because it is written in a high-available way. This makes Outline a great service to run on Zerops.

We used Slack for authentication purposes, so this tutorial is focused on that, but there are more authentication methods available. First we needed to create a Slack account in order to have SLACK_KEY and SLACK_SECRET values associated with our Slack account.

Requirements

To host Outline we need following technologies.

PostgreSQL (v12+)
Redis (v4+)
S3 compatible object storage
Node.js (v16+)

We have created a Zerops recipe for your convenience. If you want to quickly import this project, here it is.

project:
  name: outline-wiki
  tags:
    - wiki
services:
  - hostname: wiki
    buildFromGit: https://github.com/outline/outline
    pipelineConfig:
      wiki:
        build:
          base: [ nodejs@16 ]
          build:
            - yarn install --frozen-lockfile
            - yarn build
            - yarn sequelize db:create --env=production-ssl-disabled || true #skip creating db if already created
            - yarn sequelize db:migrate --env=production-ssl-disabled
          deploy: [ . ]
          cache: [ node_modules ]
        run:
          init:
            - zcli bucket s3 create s3 outline --x-amz-acl=private
          start: yarn start
    type: nodejs@16
    enableSubdomain: true
    envVariables:
      AWS_ACCESS_KEY_ID: ${s3_accessKeyId}
      AWS_REGION: us-east-1
      AWS_S3_UPLOAD_BUCKET_NAME: ${s3_serviceId|lower}.outline
      AWS_S3_UPLOAD_BUCKET_URL: https://zerops-usc1.contabostorage.com
      AWS_SECRET_ACCESS_KEY: ${s3_secretAccessKey}
      DATABASE_URL: postgres://db:${db_password}@db:5432/outline
      DATABASE_URL_TEST: postgres://db:${db_password}@db:5432/outline-test
      PGSSLMODE: disable
      REDIS_URL: redis://redis:6379
      SECRET_KEY: <insert-secret-key>
      UTILS_SECRET: <insert-util-secret-key>
      SLACK_CLIENT_ID: <insert-slack-id>
      SLACK_CLIENT_SECRET: <insert-slack-secret>
      URL: ${zeropsSubdomain}
    ports:
      - port: 3000
        httpSupport: true
    verticalAutoscaling:
      minVCpu: 1
      maxVCpu: 20
      minRam: 1.25
      maxRam: 32
      minDisk: 1
      maxDisk: 100
    minContainers: 1
    maxContainers: 4
    priority: 5
  - hostname: s3
    type: object-storage
    objectStorageSize: 2
    priority: 10
  - hostname: redis
    type: keydb@6
    mode: NON_HA
    priority: 10
  - hostname: db
    type: postgresql@12
    mode: HA
    priority: 10

This recipe creates 4 services, corresponding to 4 applications listed in the requirements section.

Wiki service (Node.js)

Everything except the Node.js service is using a default configuration, so we’re going to describe how it’s configured in this section.

First we need to tell Zerops where to find the project's source code. We do that by using buildFromGit key. By default, Zerops expects zerops.yml file in the root of the project directory. But we want to build a project from a repository that we don’t have write access to. To do that, we can specify a zerops.yml file’s content in the pipelineConfig attribute.

zerops.yml content in pipelineConfig

Now we're going to describe the content of the pipelineConfig. To build Outline we need Node.js and yarn installed. They are available in the nodejs@16 build image.

In the build section we define necessary build steps which are copied from the Outline documentation. We cache the node_modules folder, to make additional builds faster.

In the init section we need to create a bucket for Outline to save assets. ZCli can be used to automate this process, by running zcli bucket s3 create s3_hostname bucket_name. It creates a new bucket prefixed with the s3 service id. We can find the service id in the environment variable s3_serviceId. It is going to be useful in the next section when we set the environment variables.

Configuration using environment variables

Outline is cloud-ready so it is pretty straight-forward to make it work with Zerops. Let’s break down the configuration of S3.

AWS_ACCESS_KEY_ID: ${s3_accessKeyId}
AWS_REGION: us-east-1
AWS_S3_UPLOAD_BUCKET_NAME: ${s3_serviceId|lower}.outline
AWS_S3_UPLOAD_BUCKET_URL: https://zerops-usc1.contabostorage.com

If the object storage service is named s3 and the bucket created using zcli is called outline, then there’s nothing to change. Next we need to configure database connections both for the redis and postgresql. PGSSLMODE is disabled, because the whole project is on its own private network and we do not communicate with the database over the Internet.

DATABASE_URL: postgres://db:${db_password}@db:5432/outline
DATABASE_URL_TEST: postgres://db:${db_password}@db:5432/outline-test
PGSSLMODE: disable
REDIS_URL: redis://redis:6379

For signing in purposes, Outline uses 2 secrets. They can be configured using environment variables UTILS_SECRET and SECRET_KEY. To generate these keys, you can use this command from the terminal.

openssl rand -hex 32

Login and password authentication is currently not supported by Outline and so it needs to be integrated with a third party application like Slack. After creating an application as mentioned at the start of the article, you can configure Slack using the following environment variables.

SLACK_CLIENT_ID: <insert-slack-id>
SLACK_CLIENT_SECRET: <insert-slack-secret>

Finally we need to configure the url, which Outline will be hosted on. If we want to use a Zerops subdomain we can leave the URL variable unchanged. Otherwise, we need to configure public access in the Zerops GUI and input the configured url here.

Configuration of ports

On yarn start Outline starts the application on port 3000. The application uses http protocol, so we need to set httpSupport to true.

Importing the project

You can import the project in the GUI using the following button.

After a successful import you can access the wiki using the configured url or the zerops subdomain, found in the wiki service.

Conclusion

So that’s everything you need to run a self-hosted knowledge base on the Zerops platform. Outline is a really great piece of software and is cloud ready, so it fits nicely into the Zerops ecosystem.

If you have any further questions about the setup or about Zerops in general, feel free to ask for advice in our community discord.

An introduction to the Zerops build & deploy pipeline: A Golang example

Rémy Apfelbacher — Mon, 07 Nov 2022 16:00:44 +0000

Welcome back to our article series about Golang in Zerops! In case you missed the previous post, have a look at Building a Simple TODO App with Gin-gonic in Zerops: A step-by-step Guide to catch up on the basics.

In this post we will focus on building and deploying your own application in Zerops. All you need to do is add a zerops.yml configuration file to the root directory of your app. We will go in detail through the file so that it works best for your application.

1. Set up your project in Zerops

Feel free to skip this section if you are already familiar with Zerops.

Complete these steps to have Zerops ready for your application:

Login to Zerops
Create a new project
Add a new Golang service

Note down the names of the project and the service, you will need them for future reference. For our example application we created a project called myProject and a Golang service called helloworld.

1.1. Pipeline triggering (GUI/zCLI)

Once you have your zerops.yml ready, there are two options to trigger the build & deploy pipeline:

Git integration + Zerops GUI

Recommended when your app source code is already versioned in a git repository. In the detail of your Go service, go to Build, deploy, run pipeline settings, connect with either a Github or Gitlab repository and Activate pipeline trigger according to your needs.

zCLI

If command line is your best friend or it just better suits your use case, you can:

Install zCLI
Login to zCLI with an access token generated in GUI
Run a zcli push <project_name> <service_name> command (in our case it is zcli push myProject helloworld)

Nevertheless, once the pipeline is triggered, you can follow its progress in the Zerops GUI with more information provided.

1.2. Example application

The most simple example was chosen to eliminate the need to test the app locally before trying out Zerops.

You are more than welcome to build, deploy and run your own Go application in Zerops while following this example only as a guide.

Our example app is a slight modification of the famous “Hello, World!” program. There is only one file, main.go. The main function first sets up the getHelloWorld handler function to the /hello-world path, and then it starts the http server with the gin-gonic library. The getHelloWorld function only prints “Hello, World!”. The server is listening on port 8080, which is the default port created for Go services in Zerops.

package main

import (
  "fmt"
  "log"
  "net/http" "github.com/gin-gonic/gin"
)

func main() {
  fmt.Println("Running http server")

  router := gin.Default()
  router.GET("/hello-world", getHelloWorld)
  log.Fatal(router.Run(":8080"))
}

func getHelloWorld(c *gin.Context) {
  fmt.Println("received /hello-world request\n")
  c.String(http.StatusOK,"Hello, World!")
}

We also need to initialize a go module, which creates go.mod and go.sum files. You can either do it yourself or copy the contents from our repository. The project structure is as follows:

myProject
├── go.mod
├── go.sum
├── zerops.yml
└── main.go

2. Build & deploy pipeline explained

First we will illustrate the process and then explain the key words when editing the zerops.yml file. It all starts with an image. It is either created by combining a base image with prepare commands, or loaded from the cache from previous builds if nothing has changed (which contains your cached files as well). The image is then run inside a "build" container. After that, all build commands are executed and a deployment artifact is created. It is 'deployed' to another 'runtime' container, where it is run.

Now let’s have a look at the build section of the zerops.yml file where you can customize the process above for your Go services. Note that the service name is the root key in the zerops.yml file.

helloworld:
  build:
    base: # optional
    prepare: # optional
    build: # required
    deploy: # required
    cache: # optional
run:
  ...

To build your Go application, you definitely need to run the go build ... command. That’s what the required build section is for! The following command compiles our package with a single main.go source file into an executable called app.

...
  build:
    - go build -o app main.go
...

And that’s it? Well, at the moment the command would fail as we have not installed go itself and set the environment. To save you the trouble of finding the right package and going through the installation process, Zerops has created several base images with the most common dependencies preinstalled, such as go and git in go@1 base image:

...
  base: [go@1]
  build:
    - go build -o app main.go
...

In case you need to use an older version of go or want to customize the dependencies in any way, use the prepare section. It is designed for any commands you might need to execute to successfully run the build commands. For instance, have you got git or wget in mind? No problem, here is an example:

...
    prepare:
      -|
        add-apt-repository ppa:longsleep/golang-backports
        apt update
        apt install -y golang-1.17 git wget
        ln -s /usr/lib/go-1.17/bin/go /usr/bin/go
        ln -s go-1.17 /usr/lib/go
    build:
      - go build -o app main.go
...

Another required key in the build section of zerops.yml file is deploy. You need to let Zerops know which files or folders need to be deployed to a container where your application will be running. In our case we only need the app executable. The value is an array of paths allowing you to deploy single files or entire folders, see the documentation for all supported formats.

...
  build:
    base: [ go@1 ]
    build:
      - go build -o app main.go
    deploy: [ app ]
...

The last part of the build section is an optional cache. After every build the resulting image of base image and prepare commands is cached and used next time if nothing changes in these sections of the zerops.yml. However all files in your project root directory are discarded, unless you explicitly tell Zerops to cache them too. In the Go service there is not much to cache that would significantly speed up the build process compared to the node_modules folder in a Node.js service, for example. However let’s see how we can cache go dependencies as well - but take it only as an example!

It is possible to cache any files and folders in the project root directory except the .git folder. Since the default folder where the go modules are stored is ~/go/pkg/mod, we need to change it to e.g. $(pwd)/mod (working directory is by default the root of your project), and then we can cache this folder. The expected format is the same as for deploy.

...
  build:
    base: [ go@1 ]
    build:
      - go env -w GOMODCACHE=$(pwd)/mod
      - go build -o app main.go
    deploy: [ app ]
    cache: [ mod ]
...

To check that the cache is applied, you should see in the logs that the dependencies are only downloaded during the first build.

Now we are done! The last thing is to run your deployed code. The only required key for Go services is start, its value is expected to be a command that starts your application, such as ./app runs the app executable in our example.

The full working zerops.yml file to build, deploy and run our helloworld application is as follows:

helloworld:
  build:
    base: [ go@1 ]
    build:
      - go build -o app main.go deploy: [ app ]
    run:
      start: ./app

To make sure the application is up and running, open the Runtime log section in the Golang service detail.

If you have followed our example, or you have your own http server running, you can also test it by enabling a subdomain (for development purposes) or setting up your domain. Either way, when the /hello-world request is made, you should see “Hello, World!” printed.

Easy, right? :) We are well aware that the real-life application will be more complex. If you have any issues, join our Discord server to ask any questions and/or share your solutions with others. Also check our documentation to learn more about Zerops.

We are looking forward to seeing your own pipelines running!

Conclusion (tl;dr)

always specify build command
use predefined base images or specify custom prepare commands to build your app - or BOTH!
always specify which files you want to deploy to a runtime container
you can optionally cache any deployed files to speed up future builds

How to Autoscale Node.js Image Transformations Using Sharp and Express

Rémy Apfelbacher — Thu, 13 Oct 2022 09:42:57 +0000

Automation of application scaling is one of the key benefits of PaaS. The following example shows how you can use this ability in Zerops, a developer-first app platform – specifically, when transforming images by scaling or rotating them using Node.js.

Note: Please be aware that the example code is not meant to have production code quality. The purpose is to demonstrate the scaling feature of Zerops. In the following, we assume that you have a Zerops account and an installed zcli (Zerops command line tool) available.

Writing your code

The code is fairly simple. It uses Express and Sharp to perform the actual work. Thus please execute the following in a folder of your choice:

npm i express sharp

This will install all dependencies in a folder node_modules and more importantly create files package.json and package-lock.json.

Then please create the file index.js and insert the following code:

const sharp = require("sharp")
const express = require('express')
const expressServer = express()

expressServer.get('/image', (request, response) => {

  const requestedWidth = request.query.width ? parseInt(request.query.width) : 300;
  const requestedHeight = request.query.height ? parseInt(request.query.height) : 300;
  const requestedAngle = request.query.angle ? parseInt(request.query.angle) : 0;
  const format = 'jpg';

  console.log(`Handling image: size to ${requestedWidth}x${requestedHeight} and rotation to ${requestedAngle}`)

  sharp('example.jpg')
    .resize(requestedWidth, requestedHeight, {
      fit: sharp.fit.inside,
    })
    .rotate(requestedAngle)
    .toFormat(format)
    .toBuffer()
    .then(function (outputBuffer) {
      response.type(format);
      response.end(outputBuffer)
    });
})

expressServer.listen(3000, () => {
  console.log(`Listening on port 3000.`)
})

You can use any jpg image as example.jpg. Please put one in that folder.
That's it. Just regular code (and an image).

Setting up the project in Zerops

Once you have the code ready, you need to create a project in Zerops. For that purpose, please:

login to Zerops
create a project by clicking on Add new project
specify a project name e.g. image
choose Node.js as service to be added
click Set to high availability?
click add

This sets your Node.js runtime to high availability meaning it will perform vertical and horizontal scaling automatically. Vertical scaling means simply adjusting the amount of resources in your container whereas horizontal scaling adjusts the number of containers. You can read more about it here.

Build and deploy on Zerops

The following steps describe how you can build and deploy the example as a Zerops application.

For Zerops to know which files to use please also create a zerops.yml file next the other files:

nodejs0:
  build:
    base: [ nodejs@16 ]
    build:
      - npm ci
    cache: [ node_modules ]
    deploy: [ index.js, example.jpg, node_modules ]
  run:
    start: node index.js

Simply deploy your file

zcli push "image" nodejs0

Enable Zerops subdomain access via Public access & internal ports on the nodejs0 service and invoke the pre-generated URL in your browser.

Autoscaling in action

So far we deployed the code only without seeing the autoscaling in action. For that purpose we will use k6 to generate some load.

No worries, Zerops won't scale to infinity without keeping your expenses under control. You can adjust the maximum and minimum resources for both vertical and horizontal scaling easily every time you see fit. Zerops will do the rest.

Here the script to generate some load k6.js:

import http from 'k6/http';
import { check } from 'k6';

export default function () {
  const baseUrl = "https://<your-generated-subdomain>.usc1.contabozerops.com"
  const width = 300 + Math.random() * 1000
  const height = 300 + Math.random() * 1000
  const angle = Math.random() * 360
  const res = http.get(`${baseUrl}/image?width=${width}&height=${height}&angle=${angle}`)
  check(res, {
    'is status 200': (r) => r.status === 200,
  });
}

And then run it by invoking

k6 run --vus 100 --duration 120s k6.js

This will simulate a 100 users requesting the image service as fast as possible during 120 seconds.

Our example is mainly a CPU-intensive task so you will see the number of vCPUs (virtual CPUs) rise -- vertical scaling -- and after a short time also see more containers being created -- horizontal scaling. Please refer to the following screenshot where you see many vCPUs and 4 containers.

After the k6 script finished generating the load, Zerops will wait for a moment to make sure the demand has really gone down. Then you'll first see the vertical autoscaling taking action by reducing vCPUs (due to the nature of our example). The number of vCPUs has dramatically decreased.

After a while, Zerops will perform the horizontal autoscaling as well. As the k6 script finished generating load and we don't have any more coming, the starting point with two containers will be reached as shown in the screenshot.

Summary

Zerops is performing both vertical and horizontal autoscaling out of the box with a single click. Just like shown in the example above. No need to have a special code or knowledge. It both saves money and gives you more power when required.

For a deeper dive into what’s happening behind the scenes of Zerops autoscaling, check out my previous article.

Building a Simple TODO App with Gin-gonic in Zerops: A step-by-step Guide

Rémy Apfelbacher — Fri, 23 Sep 2022 07:42:45 +0000

Building APIs is bread and butter for most programmers. The Zerops app platform makes this process even easier by taking care of the infrastructure.

In this article, we will show you how simple it is to build a sample CRUD TODO API written in GO using gin-gonic, one of the most popular web frameworks, which saves your data to the PostgreSQL database.

The resulting project is available here.

Getting started

First and foremost we need a database system to store and manage our data. In this case, we chose PostgreSQL.

Side note: If you prefer a different technology, such as MariaDB, which Zerops also supports, the process is analogous and the source code can be found here.

Let's start by running a PostgreSQL server. We can create one very easily in Zerops, either manually or via the Zerops import function. Simply create a new project and add a PostgreSQL service (here’s more about PostgreSQL in Zerops).

To test the connection or for local development, we can connect to the server with Zerops’ own command line utility called zCLI. After you have installed the zCLI, follow these simple steps to log in using a personal access token. The last step is to start a VPN connection by running

$ zcli vpn start [projectName]

Now we should be able to test that the server is accessible by running

$ ping6 [hostname].zerops # in our case postgresql0.zerops

Golang

Dependencies

We will create the API as a GO module for easier versioning and reproducibility of builds. New GO modules are created with:

$ go mod init [api-name]

This command creates two files, go.mod and go.sum, which both contain dependency information.

The following GO packages are used in this example:

and they can be installed using

$ go get [package-url]

More information on how to use go modules can be found here.

Folder structure

This being a sample application, the project structure is very simple.

todo-api/
├── http.go
├── main.go
├── model.go
├── go.mod
├── go.sum
├── schema.sql
└── zerops.yml

The API source code is contained in the following files:

http.go - relating to the HTTP server
model.go - for communication with the DB
main.go - initialization and wiring of dependencies together

This is the bootstrap of the Gin framework which is enough for it to run in Zerops. The following is our implementation of the HTTP server.

First of all, we need to initialize the server in main.go by calling

r := gin.Default()

To run the HTTP server smoothly, and not just in Zerops, we use several middlewares. They include CORS support, better error logging that logs to the Zerops runtime log, and a content-type header addition, which is an example of custom-written middleware.

To see the logs in Zerops runtime log, we need to add the following middleware to the gin server. It handles errors and returns 500/4xx error codes depending on the error type. Additionally, it logs failed http requests with 500 to the stdout for Zerops to render on the frontend.

r.Use(gin.ErrorLoggerT(gin.ErrorTypePublic | gin.ErrorTypeBind))

Now that we are done with the basic server setup, all that’s left is to register the endpoints. First, we create a router group that will consist of routes with the same path prefix.

g := r.Group("todos")

This API contains CRUD operations for working with the todo resource. We register each url path to a handler, which processes the corresponding HTTP request.

g.GET("", handler.getTodos)
g.GET("/:id", handler.getTodo)
g.POST("", handler.createTodo)
g.PATCH("/:id", handler.editTodo)
g.DELETE("/:id", handler.deleteTodo)

We have chosen the getTodos handler as an example in this blog post. For the full list of handlers, consult the http.go file.

func (t todoHandler) getTodos(c *gin.Context) {
    todos, err := t.model.FindAll(c.Request.Context())
    if err != nil {
     internalServerError(c, err)
     return
    }
    c.JSON(http.StatusOK, todos)
}

Finally, we can run this server on port 3000 using the following code in the main.go.

log.Fatal(r.Run(":3000"))

Running the API locally

In the main.go file there are 3 environment variables used to connect, migrate, and seed the database. We can do this by creating an .env file with following content:

ZEROPS_RECIPE_DATA_SEED=["Buy milk", "Write Zerops article"]
ZEROPS_RECIPE_DROP_TABLE=1
DB_URL=postgres://${user}:${password}@${hostname}:5432/${hostname}

To get the user, password and hostname values, see environment variables in Zerops GUI.

Make sure you have the zCLI VPN up and running to proceed here.
Run this command to set the environment variables and run the API:

$ source .env && go run main.go http.go model.go

Running the API in Zerops

After we completed the development of the API, and tested its functionality locally, it's time to deploy it to Zerops. To do that, we need to create a configuration file called zerops.yml, which contains steps to build and deploy our app. For GO, this file is rather simple and looks like this:

api:
  build:
    base: [ go@1 ]
    build:
      - go build -o app main.go model.go http.go
    deploy: [ app ]
  run:
    start: ./app

The simplest way to deploy our API to Zerops is to integrate it as an external GitHub or GitLab repository. We need to create a Golang service in Zerops. The easiest way to configure the API is to paste the environment variables in the .env file format, defined in Running the API locally.

Once the service is created, we enable a subdomain, which is a domain used for development and testing purposes. When we access it, we will see a response with todo entries from the ZEROPS_RECIPE_DATA_SEED variable.

That's it!

Conclusion

Hopefully, you managed to follow this article and deploy the API to Zerops successfully. If you have any further questions, visit our Discord channel.

Scaling Your Apps Automatically with Zerops – Both Vertically and Horizontally

Rémy Apfelbacher — Wed, 21 Sep 2022 10:42:56 +0000

Auto scaling is one of the key features of PaaS systems, such as Heroku or Render. That is why we made sure to include it in Zerops and to finetune it to developers’ needs.

What is autoscaling?

This feature performs an automated scaling of resources required to run your application based on its demand. So if your application isn’t used so often the auto scaling reduces the amount of required resources and thus reduces the costs. If your application is used more, then auto scaling increases the resources for the application to make sure it runs smoothly even with the higher demand.

The result?

On Zerops, you never pay for resources you don’t need. At the same time you don’t have to worry about traffic peaks or fast growth as the auto scaling feature handles this with no trouble.

Zerops automatically scales services both horizontally and vertically

Each service you install starts with the minimum technical amount of resources: vCPU, RAM and Disk. Zerops monitors the usage of these 3 resources and if the usage exceeds a set threshold, more vCPU, RAM or Disk is allocated to the service. This is called vertical scaling.

When creating a new runtime service, you can choose the minimum and maximum number of containers. If you set the maximum limit to one, the service will be run in a single container and no horizontal scaling will occur. By increasing the maximum number of containers for your service, you enable horizontal auto scaling. Zerops will then add containers depending on your application’s load. Application running on two or more containers is in High-Availability mode, which we highly recommend for production. When the load drops, containers will be gradually removed to the defined minimum.

Each container and each metric (vCPU, RAM, Disk) is scaled separately. If you run your application in High-Availability mode, different containers can allocate different amounts of resources based on the current usage. There are no fixed tiers or pricing packages, you pay only for the performance and storage your application needs.

Auto scaling configuration for runtime services

Both minimum and maximum limits for auto scaling are under your control. Technical minimums for vCPU, RAM and Disk are preset for each runtime service. Set the minimums and maximums for vCPU, RAM and Disk depending on the needs of your application and Zerops will scale them within defined limits. You can change the settings any time, Zerops will update the number of containers and their allocated resources accordingly.

Vertical auto scaling of vCPU, RAM or Disk can be disabled independently by setting the same value for minimum and maximum. For example, you can control your RAM manually and let Zerops scale vCPU and Disk automatically.

Horizontal scaling can be disabled by setting the same number for the minimum and maximum container count. Zerops then scales the service only vertically.

Auto scaling configuration for databases

Vertical auto scaling configuration for databases and shared storage is identical to runtime services. Technical minimums for vCPU, RAM and Disk are preset according to the service type and version.

You can choose 2 modes for each database and shared storage: Single Container or Highly Available mode. In the Single Container mode the database or shared storage is deployed in a single container. The number of containers cannot be increased.

If the Highly Available mode is chosen, Zerops will deploy the database cluster with a fixed number of containers and control mechanisms for automatic cluster repair. Shared storage cluster contains 3 containers with all files redundantly stored on all 3 containers. The KeyDB (Redis) cluster consists of 2 containers in the master-master replica. MariaDB, PostgreSQL databases and RabbitMQ message broker are deployed in 3 containers connected in the High Availability cluster with 2 additional application balancers which ensures high reliability. You are not charged for the resources consumed by application balancers.

Object Storage

Amazon S3 compatible object storage is operated as a CEPH cluster and is always in the Highly Available mode. When creating a new object storage service, you set the Disk Capacity and Zerops takes care of the rest. You will be charged for the allocated disk space only. You can change the disk capacity on the go. Object storage doesn't scale automatically.

Zerops Auto Scaling Mechanisms

Zerops prefers vertical scaling over horizontal scaling because vertical scaling is faster and allows finer adjustment to the required performance. Zerops checks vCPU, RAM and Disk usage in all running containers each 10 seconds. If a threshold for vertical scale up is reached, Zerops scales the container up. The minimum step for the vertical scaling is 1 vCPU, 0.25 GB RAM and 0.5 GB Disk, when the application is under a heavy load and needs to scale up fast, the steps will be automatically increased. After the application no longer needs as much power or disk space, each container is gradually scaled down to the defined minimum.

Zerops will add a new container (scale out your service) when a single container reaches the maximum defined limit for vertical scaling of vCPU or RAM. Zerops doesn't start a new container when the maximum disk space is reached or when the maximum container count is reached.

By customizing the vertical auto scaling limits, you can cause the horizontal scaling to start earlier. For example set the vertical auto scaling maximum to 10 vCPU. Zerops will start a new container if some of the running containers are using the 10 vCPU for more than a minute.

If the application no longer needs as much power, Zerops will gradually remove containers to the defined minimum count.

Find out more about Zerops.

Hello world: Zerops Edition

Rémy Apfelbacher — Tue, 13 Sep 2022 17:19:50 +0000

One of the most famous examples in programming is the iconic "Hello world". To follow this tradition, we use this very example to show all the steps needed for turning existing or new code into a working application powered by the new cloud application platform called Zerops.

First things first: What is Zerops?

Zerops is a recently introduced PaaS such as Heroku or Render. Like them, it aims to be a universal platform that builds, deploys, runs, and manages your apps for you, be it a tiny project in development or a large one in production.

With Zerops, you have a wide array of options when it comes to what you can run. You can opt for anything from a simple static web server to several runtimes for different programming languages backed up by various database management systems and other storage systems.

Getting back to our “Hello world” example

To simplify matters we are omitting any extra steps such as connecting to GitHub and only focusing on the first steps. However, to increase the level a bit, we will take a look at two possible scenarios:

Using a static web server
Using a Node.js runtime

In both cases we assume that you already have a Zerops account and an installed zCLI (Zerops command line tool) with proper authentication set up. Please note that you could use any other runtime like for Golang or PHP.

"Hello world" – the simplest way

Create your index.html file with the following content:

<!DOCTYPE html>
<html>
<body>
  <h1>Hello world from Zerops!</h1>
</body>
</html>

Login to Zerops GUI, create a new Hello world project and add the Static server service with the chosen hostname staticserver0.
Then simply deploy your file using the zCLI command:

zcli deploy "Hello world" staticserver0 index.html

Enable Zerops subdomain access via Public access & internal ports on the staticserver0 service and invoke the pre-generated URL in your browser.

Et voilà.

"Hello world" – still a simple way using Node.js

Create your index.js file with the following content:

const http = require('http')

const requestHandler = (request, response) => {
  response.end('Hello world from Zerops!')
}

const server = http.createServer(requestHandler)
server.listen(3000);

For Zerops to know how to start the application, please create a zerops.yml configuration file next to it:

nodejs0:
  build:
    build: []

  run:
    start: node index.js

Login to Zerops GUI and create a new Hello world (js) project and add the Node.js service with the chosen hostname nodejs0.
Then simply deploy your file using the zCLI command:

zcli deploy "Hello world (js)" nodejs0 index.js

Enable Zerops subdomain access via Public access & internal ports on the nodejs0 service and invoke the pre-generated URL in your browser.

All done! Congrats.

Summing things up

We went through the basic steps of deploying an application to Zerops. You could see how simple it was. As you may have noticed from the sample zerops.yml files, on Zerops, you can take complete control of the building, deploying, and running of your code.

Coming up: more in-depth articles on how to make the most of Zerops.