DEV Community: Jon Friesen

Review: Learn Concurrent Programming with Go

Jon Friesen — Thu, 22 Feb 2024 00:00:00 +0000

Go has been my primarily language for the last ~6 years, however, until now I’ve primarily been a consumer of libraries that employ high levels of concurrent programming and had minimal experience implementing these patterns on my own let alone in a production setting.

I stumbled upon Learn Concurrent Programming with Go in a Reddit post by the author, James Cutajar announcing it’s release.. My first impression was “that’s neat” and moved along with my daily reddit based procrastination routine before quickly scrolling back searching in earnest for as this is a skill I wanted to get better at.

James does a fantastic job of reviewing the foundational requirements for a developer, touching on concurrency topics like processes vs threads, and then dives into patterns using the Go standard library tooling to demonstrate these. Taking time to explain topics like communicating sequential processes (CSP) and then implementing variations of patterns described in CSP with Go.

The book excels at keeping the density of information vs the pace of the book at a really consumable speed for your average developer. The strength of this books versus other sources on concurrency and concurrency with Go are that it really focuses on teaching the fundamental patterns with what’s going on under the hood; the lessons learned here are immediately applicable to Go programs, but even more so a skill that is transferrable to other languages, systems, and frameworks.

The weakest part of Learn Concurrent Programming with Go is the cartoon diagrams which I found difficult to follow and ended up largely ignoring.

Overall I’m super happy my purchase and would recommend this to Go developers early in their Go journey as it’s a great example of applying known concurrency patterns in Go, as well as experienced Gophers who want to brush up on their concurrency knowledge in a language they’re familiar with.

How to create GitHub Actions test summaries for Go

Jon Friesen — Thu, 09 Nov 2023 00:00:00 +0000

One of my pet peeves is searching CI output for test failure details. While I realize that in many cases this is a necessity, in most cases I think this can be avoided using test output summaries. Luckily, there are two open source tools we can take advantage of to easily implement test summaries in GitHub Actions and Go tests.

First we need to generate the test summary xml file. The tool I commonly use across my test running needs is gotestyourself/gotestsum. This is a great tool for grouped console outputs and generating nice junit xml outputs.

Install with:

go install gotest.tools/gotestsum@latest

gotestsum is a drop-in replacement for go test, so we can someone easily replace this in our GitHub Action workflow:

    - name: Test
    run: go run gotest.tools/gotestsum@latest --junitfile unit-tests.xml --format pkgname

This simple workflow step will run the tests in the current folder, grouping by package name, and save the summary to a unit-tests.xml file. In cases where there are different styles of tests, (eg. unit, integration, e2e) running this multiple type and creating sepearate junitfiles is helpful.

Now we need to run our final step of persisting the test files as action summaries, to do this we will take advantage of the test-summary/action project. Added to our workflow file as:

    - name: Test Summary
    uses: test-summary/action@v2
    with:
        paths: "unit-tests.xml"
    if: always()

This step will persist the test summaries and make them accessible to GitHub Actions for display. Providing an output like:

Full Workflow Sample:

name: build

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Set up Go 1.19
        uses: actions/setup-go@v1
        with:
          go-version: 1.19
        id: go

      - name: Check out code
        uses: actions/checkout@v1

      - name: Test
        run: go run gotest.tools/gotestsum@latest --junitfile unit-tests.xml --format pkgname

      - name: Test Summary
        uses: test-summary/action@v2
        with:
          paths: "unit-tests.xml"
        if: always()

Go Explored: new() vs make()

Jon Friesen — Sat, 27 May 2023 00:00:00 +0000

The Go standard library includes two built-in functions that are commonly used, though in many cases are not totally clear about what they are doing behind the scenes and why they are being used. They are new() and make().

As a side note: this blog post is more of a reminder to myself about what these do.

The `new()` function

The new() function can instantiate any struct or value data type. When new is called, Go will allocate the memory without initializing it. This means that the memory reserved is "zeroed". When new is called with a data type it will return a pointer to a zero value memory location of the type you've specified.

Here's a simple example:

i := new(int)
fmt.Println(*i)
// prints: 0

In the above example new(int) reserves space for an integer, initializes that space to zero, and returns a pointer to it. Like most Go variables, the space is released by the garbage collector when the pointer is no longer referenced.

Example

new() would be used when you want to allocated a zeroed value for the pointer it creates. This is useful when working with basic types or custom structs.

type Person struct {
    Name string
    Age int
}

p := new(Person)
fmt.Println(*p)
// prints: { 0}

The `make()` function

make() has a much tighter scope as it can only instantiate channels, maps, and slices and returns an initialized value (not a pointer) which is not zeroed. The data structure of the type is ready for use.

Here's a simple example:

s := make([]int, 5)
fmt.Println(s)
// prints: [0 0 0 0 0]

In the above example make([]int, 5) creates a slice of integers with a length of 5 where all elements within are initialized to zero.

Example

make() is used when you're want to prepare a channel, map, or slice. This is optimal in situations where you know the starting amount of resources you'll be inserting into these datastructurs. This removes the need for reallocated when setting up the contents of a structure.

// channel example
ch := make(chan int)
go func() { ch <- 1 }()
fmt.Println(<-ch)
// prints: 1

// map example
m := make(map[string]int)
m["one"] = 1
fmt.Println(m) // prints: map[one:1]

// slice example
s := make([]int, 10)
fmt.Println(s) // prints: [0 0 0 0 0 0 0 0 0 0]

In all three of the above examples, the data structure is created and ready for immediate use. In the case of the slice example, there are 10 spots already allocated and ready for data.

Instantiating

Both of these built-in's shouldn't (necessarily) be the go-to methods for creating their respective types. There are specific contexts when it makes sense to use them.

`new()`

Using new() is great when you need a pointer and that's all. If you already have a value (eg. an int) to be assigned then you could just create that i := 1 and if reference the pointer like p := &i. A common use case for creating a pointer is when functions take a pointer and alter the underlying data.

func main() {
    year := new(int)

    if err := GetYear(year); err != nil {
        panic(err)
    }

    fmt.Println("The year is:", *year)
}

func GetYear(i *int) error {
    if *i != 0 {
        return fmt.Errorf("expected 0 value")
    }

    *i = time.Now().Year()
    return nil
}

When using new(), &, or another style of instantiating, you should review the specific requirements of your code given it's context and pick the clear and concise form.

`make()`

make() is very powerful when you have an idea of what kind of space and records your structure will require. For example, a program may have a set of 5 values coming in that it wants to put in a slice, and that slice will likely grow to 15 total values. The slice can be prepped like s := make([]int, 5, 15).

The 5 represents the amount of zeroed values that will be included in the slice. The 15 is the allocated space that will be available reserved for that slice. This means that up to 10 more values can be added before the slice space needs to be reallocated and expanded.

Looping over this slice would look like:

for _, i := range s {
    fmt.Print(i, ",")
}
// prints 0,0,0,0,0,

Note, that it only prints five 0's. This is because those have been instantiated. Some more examples:

var s1 []int // length and capacity are 0
s2 := []int{} // length and capacity are 0
s3 := []int{1, 2, 3} // length and capacity are 3
s4 := make([]int, 3) // length and capacity are 3
s5 := make([]int, 3, 100) // length is 3, capacity is 100

In the above examples length is the amount of instantiated, zero values, and capacity is the amount of spaces resevered in memory.

Conclusion

Understanding how and when to use Go's built-in functions new() and make() can make a substantial difference in how you handle memory allocation and initialization in your Go programs.

new() and make() serve different purposes. new(T) is used to allocate zeroed memory for a variable of type T and returns a pointer to it, useful for all types. This is particularly helpful when you need to obtain a pointer of a zero value of any data type, such as basic types or custom structs.

make(), on the other hand, is designed to create complex data types like slices, maps, and channels with an underlying structure that's ready for use. It allows you to initialize these types and specify their capacity right off the bat, saving you from the costly process of memory reallocation when the data structures need to grow.

But remember, although new() and make() are powerful, they are not always the best tools for the job. Regular variable declaration and initialization using var or := is often clearer and more idiomatic. In case of new(), if you already have a value to assign to the variable, you might not need new(). Instead, you can use := to declare and initialize the variable, then & to get its address if necessary.

In the case of make(), while it's great when you have a clear idea of the capacity your data structures require, for small data structures or if you don't have a capacity in mind, using slice literals or declaring a map or channel directly can be simpler and clearer.

At the end of the day, the key to writing efficient, clear, and idiomatic Go code is to understand these tools and choose the right one for your specific use case. Happy coding!

Docker in Docker access for non-root users

Jon Friesen — Wed, 09 Nov 2022 00:00:00 +0000

Mounting a host machine docker daemon within a docker container is really as simple as starting the container with a volume pointing at the hosts docker socket, for example:

docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock \
    ubuntu /bin/bash

The socket is mounted, huzzah! From here the user could install docker with apt install docker.io and be on their way. This method should work on both Linux and Mac machines. Windows machines a bit more complicated because the docker daemon needs to be remotely enabled to be accessed via a tcp connection. I'm not going to cover Windows here.

To add some complexity, running docker as a non-root user without doing a privilege escalation (like sudo) won't "just work" as the above example does. Beyond creating a dockerfile, mounting the docker socket, and creating a user there are bunch of permission "things" that need to be done to allow access.

The thing that may have brought you here is this error:

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.40/containers/json: dial unix /var/run/docker.sock: connect: permission denied

So, why wouldn't you want to run the docker container as root? Wellllll, there are a few reasons, security, sandboxing, not giving the user root is generally a good thing. Though there are other reasons. I went down this rabbit hole because I wanted to build and run some tests within the container, these tests verified some created files were read only, but as root, no matter the permission, they were always readable which failed the test. This is different then our production configuration which worked correctly, so finding a way to get the container to mimic a production deployment was essential for having confidence in the tests.

Okay, let's get into it. The docker file will look something like:

# dockerfile:
FROM ubuntu:jammy

# install the docker client and sudo
RUN apt update && apt install -y docker.io sudo

# add 'myuser' with bash as the default terminal
# and setup the user home tree
RUN useradd myuser -s /bin/bash -m

# copy in our entrypoint script
COPY docker-entrypoint.sh /docker-entrypoint.sh

# initiate our entry point script
ENTRYPOINT ["docker-entrypoint.sh"]

It's important to note that we don't set the current user before running the dockerfile. This is because we need to setup the aformentioned permission "things" as root then we can move to execute the workload as the myuser user.

The entrypoint script:

# docker-entrypoint.sh:
#!/usr/bin/env bash

# verify the docker.sock is present in the container
# if this fails it's because the socket wasn't mounted
if [[! -S /var/run/docker.sock]]; then
    echo "docker socket is missing"
    exit 1
fi

# verify the docker.sock has read and write permissions enabled
if [[! -r /var/run/docker.sock || ! -w /var/run/docker.sock]]
then
    echo "docker socket is missing read/write permission"
    exit 1
fi

# get the group id of the docker socket
# this is inherited from the host machine
gid=$(stat -c '%g' '/var/run/docker.sock')

# lookup the group by id within the container
# if it's missing, swallow the error and create the group
# using the inherited socket group id called 'docker'
if ! getent group "$gid" >/dev/null; then
    addgroup --gid "$gid" docker
fi

# get the name of the group by group id.
# this doesn't necessarily have to be called 'docker'
# it could have different names on both the host machine
# and container due to system differences or group id collisions
gname=$(getent group "$gid" | cut -d: -f1)

# check if the group name is in the list of groups that
# 'myuser' has membership too. If not, add them.
if ! groups myuser | grep --quiet "\b${gname}\b"; then
    usermod --append --groups "$gid" myuser
fi

# finally switch to our user and use the legacy buildkit.
# it's important to use the legacy buildkit because of version
# mismatching running on Docker for Desktop and a minimal linux
# installation.
sudo -u myuser DOCKER_BUILDKIT=0 "$@"

Most of the script seems pretty straight forward until we arrive at the permission "things". This section of the script is super important because non-root users are unlikely to be in the correct group by default to have execution read/write privilege to the docker socket which brings it's permissions from the host machine.

This seems pretty hacky (and it kinda is) however, the alternative which popped in my mind is why don't we just change the permissions on the mounted docker socket? Well, because that would remove the ability for the daemon user on the host machine to continue working on it and effectively break until those permission are reset.

Finally, building and running the container is pretty straight forward, building:

docker build -t docker-in-docker .

and running has two possible parameters:

# linux
docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock \
    docker-in-docker some-command

# macos (note the '.raw' on the end of the docker.sock)
# this .raw isnt necessary if running as the root user
# but is if you're not
docker run -it --rm -v /var/run/docker.sock.raw:/var/run/docker.sock \
    docker-in-docker some-command

As a small disclaimer, the techniques I covered here are great for testing, CI/CD tooling, one-off's, but definitely should not be run as a standard production environment. Mounting docker in docker brings in all sorts of risk and issues.

Finally, I'd like to give a quick shout out to my colleague and friend Kamal who got me through the permission chunk of this!

App Platform: Automatically deploy pre-built container images on push

Jon Friesen — Mon, 10 Oct 2022 00:00:00 +0000

App Platform has supported running container images from DigitalOcean Container Registry (DOCR) from the very start, however, a much requested feature is the ability to autodeploy a container when the a new image was pushed to a specific tag. With the most recent release this feature has been added and is available for all!

Note: this feature is not supported for DockerHub.

How autodeploy works

When autodeploy is enabled for a DOCR Image component in App Platform the container registry is monitored and upon a new image push App Platform checks the image digest for a target tag and if it is different than the most recently deployed version that new image is deployed.

So this means that when pushing a tag you'll probably want to use a descriptive tag that represent the latest version of that image. For example, production, staging, dev are common.

Enabling autodeploy

UI: During creation

When creating an App or Component, select your DOCR repository and image, then check the Autodeploy checkbox.

UI: Exising image components

If you already have a DOCR Image deployed autodeploy can be enabled in the settings of that component.

App Spec: Enabling within the spec

For power users, enabling autodeploy is as easy as adding a small yaml structure to your existing image spec:

deploy_on_push:
  enabled: true

for example:

name: docr-autodeploy-example
region: ams
services:
- http_port: 8080
  image:
    deploy_on_push:
      enabled: true
    registry_type: DOCR
    repository: go-info-webserver
    tag: latest
  instance_count: 1
  instance_size_slug: basic-xxs
  name: go-info-webserver
  routes:
  - path: /

An GitHub Actions example

As a fan of GitHub Actions, here's a simple workflow that does the following:

Builds the docker image with two tags:
1. the git commit short hash
2. latest
Installs the doctl commandline tool
Authenticates with the registry attached to a DigitalOcean account
Pushes the image with all tags

Paired with the app spec above which targest the latest image tag, when the underlying image changes (via digest checking) the new image will be deployed. If the digest has not changed no deployment will occur.

name: Push Docker Image to DOCR

on:
  push:
    branches: ["master"]
env:
  REGISTRY: "registry.digitalocean.com/jon"
  IMAGE_NAME: "go-info-webserver"
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Build the Docker image
      run: docker build --file docker/Dockerfile --tag $(echo $REGISTRY)/$(echo $IMAGE_NAME):$(echo $GITHUB_SHA | head -c7) --tag $(echo $REGISTRY)/$(echo $IMAGE_NAME):latest .

    - name: Install doctl
      uses: digitalocean/action-doctl@v2
      with:
        token: ${{ secrets.DIGITALOCEAN_ACCESS_TOKEN }}

    - name: Auth with DOCR
      run: doctl registry login --expiry-seconds 1000

    - name: Push image to DOCR
      run: docker push $(echo $REGISTRY)/$(echo $IMAGE_NAME) --all-tags

When an image is pushed to a registry with a tag that has already been used, the new image will take that tag, untagging the old image.

Adding middleware to Go HTTP client requests

Jon Friesen — Wed, 05 Oct 2022 00:00:00 +0000

The Go standard library has fantastic support for making HTTP requests. However, sometimes, a request needs to be modified or an action needs to be taken upon response (eg. logging a response).

In many cases, adding these logs to the every request would involve a lot of duplicate code. In other cases accessing the client might not be possible because of restricted access in a different package or third party library. Thus, I introduce RoundTrippers.

A RoundTripper can be added to an http client and executes a http transaction allowing the request to be inspected and modified and the response to be inspected and modified.

A RoundTripper can be set on a http client Transport. The interface looks like:

type RoundTripper interface {
    RoundTrip(*http.Request) (*http.Response, error)
}

and a RoundTripper is set on a client like:

client := &http.Client{
    Transport: myRoundTripper,
}

The http.Client will resolve to the DefaultTransport if the client transport is nil. It's fairly easy to chain RoundTrippers as middleware, the DefaultTransport round tripper should be considered as a base since it comes with handy defaults:

var DefaultTransport RoundTripper = &Transport{
    Proxy: ProxyFromEnvironment,
    DialContext: defaultTransportDialContext(&net.Dialer{
        Timeout: 30 * time.Second,
        KeepAlive: 30 * time.Second,
    }),
    ForceAttemptHTTP2: true,
    MaxIdleConns: 100,
    IdleConnTimeout: 90 * time.Second,
    TLSHandshakeTimeout: 10 * time.Second,
    ExpectContinueTimeout: 1 * time.Second,
}

Now that the basics have been covered we can use a single chaining example which I originally saw by Philipp from GoWebExamples.com applied to web server middleware. It's a simple little pattern that's easy to understand.

// internalRoundTripper is a holder function to make the process of
// creating middleware a bit easier without requiring the consumer to
// implement the RoundTripper interface.
type internalRoundTripper func(*http.Request) (*http.Response, error)

func (rt internalRoundTripper) RoundTrip(req *http.Request)
                                            (*http.Response, error) {
    return rt(req)
}

// Middleware is our middleware creation functionality.
type Middleware func(http.RoundTripper) http.RoundTripper

// Chain is a handy function to wrap a base RoundTripper (optional)
// with the middlewares.
func Chain(rt http.RoundTripper, middlewares ...Middleware)
                                                    http.RoundTripper {
    if rt == nil {
        rt = http.DefaultTransport
    }

    for _, m := range middlewares {
        rt = m(rt)
    }

    return rt
}

From here writing custom middlewares for your needs is straightforward. Two examples below:

CustomTimer executes a function after the RoundTrip has finished and shows the time since. This demonstrates how operates can occur before the request is made, in this case we are capturing the start time and then executing code after the request has been made using a defer.
DumpResponse prints the response body to stdout. Similarly to CustomTimer, a defer is used to run the dump after the request has been made. The difference here is named response are used to access the response data.

// CustomTimer takes a writer and will output a request duration.
func CustomTimer(w io.Writer) Middleware {
    return func(rt http.RoundTripper) http.RoundTripper {
        return internalRoundTripper(func(req *http.Request)
                                            (*http.Response, error) {
            startTime := time.Now()
            defer func() {
                fmt.Fprintf(w, ">>> request duration: %s",
                    time.Since(startTime))
            }()

            return rt.RoundTrip(req)
        })
    }
}

// DumpResponse uses dumps the response body to console.
func DumpResponse(includeBody bool) Middleware {
    return func(rt http.RoundTripper) http.RoundTripper {
        return internalRoundTripper(func(req *http.Request)
                                    (resp *http.Response, err error) {
            defer func() {
                if err == nil {
                    o, err := httputil.DumpResponse(resp, includeBody)
                    if err != nil {
                        panic(err)
                    }

                    fmt.Println(string(o))
                }
            }()

            return rt.RoundTrip(req)
        })
    }
}

Once you've written middleware that fits your needs, adding them to your HTTP client is as easy as creating an http.Client and setting the Transport.

client := http.Client{
    // Using the Chain function, we can add middlewares to our base
    // RoundTripper. These middlewares will run on every http request. 
    Transport: Chain(nil, CustomTimer(os.Stdout), DumpResponse(false)),
}

// Start making requests
_, err := client.Get("http://jonfriesen.ca")
if err != nil {
    panic(err)
}

Another great use for RoundTripper middleware is within third party clients. For example, the GitHub Go library does not have native support for adding headers to requests it makes. It's common for third party clients to support setting the http.Client, for example:

// AddHeader adds a header to the request.
func AddHeader(key, value string) Middleware {
    return func(rt http.RoundTripper) http.RoundTripper {
        return internalRoundTripper(func(req *http.Request)
                                            (*http.Response, error) {
            header := req.Header
            if header == nil {
                header = make(http.Header)
            }

            header.Set(key, value)

            return rt.RoundTrip(req)
        })
    }
}

func main() {
    userClient := github.NewClient(&http.Client{
        Transport: Chain(nil, AddHeader("key", "value")),
    })
}

App Platform: Hosting static NextJS projects

Jon Friesen — Mon, 19 Sep 2022 00:00:00 +0000

App Platform has great support for static sites, building and pushing projects to over 100 points of presence around the world ensuring the fastest load times for users. NextJS is provides a great developer experience, however opinionated and can require some unique platform services to be hosted while remaining free or very low cost.

App Platform does not employ this functionality (as of today) but that's not an issue because this can be worked around!

NextJS configurations

In your next.config.js folder you're going need a couple additions:

// next.config.js
module.exports = {
    /**
     * NextJS requires serverside components to do image optimization.
     * Unfortunately, hosting via SSG/Static means you will miss out on
     * this utility which will provide appropriately sized images for
     * the devices users are accessing your app from.
     * 
     * As a side note, you can write a custom image loader which
     * reimplements this functionality but that is beyond the scope of
     * this article.
     */
    images: {
        unoptimized: true,
    },

    /**
     * Trailing slashes places the generated pages of a nextjs app
     * within a folder.
     * 
     * Eg. instead of having an `about.html` a `about/index.html` will
     * be generated.
     * 
     * This provides pretty urls, so instead of
     * `your-app.com/about.html` you'll have `your-site.com/about`.
     * 
     * This is optional.
     */
    trailingSlash: true,
}

In addition you will need to update the build command that is used to generate your app. This can be done in a few different places, I prefer to add it to my package.json:

{
    // ...
    "scripts": {
        // .../
        "build": "next build && next export -o build",
        // ...
    },
    // ...
}

Note the -o build argument, this will put your static site in a build directory. It's a good idea to add this to your .gitignore.

App Platform configurations

Create your app using the wizard in the DigitalOcean Apps cloud dashboard. Ensure that you use the appropriate build command, eg from above:

npm run build

You will need to set your catchall in Settings > <your_component> > Custom Pages. Set this value to index.html.

Some NextJS apps will require a NEXT_PUBLIC_SITE_URL environment variable. With App Platform bind variables can be used to create an environment variable for your static site component like:

NEXT_PUBLIC_SITE_URL=${APP_URL}

Note: ${APP_URL} will be auto-filled with the apps primary URL whether that is a custom URL or the provided some-value.ondigitalocean.app domain.

Finally, ensure that your output directory in the same component settings from above is set to the build directory. If you used my example above of -o build then this directory will be build.

App Platform apps are described via an app spec, here's an example app spec that is configured for a NextJS SSG project (it's this site 😉).

domains:
- domain: jonfriesen.ca
  type: PRIMARY
  zone: jonfriesen.ca
name: portfolio
region: tor
static_sites:
- build_command: npm run build
  catchall_document: index.html
  environment_slug: node-js
  envs:
  - key: NEXT_PUBLIC_SITE_URL
    scope: BUILD_TIME
    value: ${APP_URL}
  github:
    branch: main
    deploy_on_push: true
    repo: jonfriesen/jonfriesen.ca
  name: portfolio
  output_dir: build
  routes:
  - path: /
  source_dir: /

Handling container shutdowns in app code

Jon Friesen — Mon, 15 Aug 2022 00:00:00 +0000

Most small apps start out running on a PaaS these days such as DigitalOcean App Platform. Platforms like these control the environment pre and post app execution. This isn't a problem when it comes to pre-execution as you can run your startup tasks when your app is started.

However, running clean up code when the app, or more specifically the container is being shutdown isn't as straightforward. This is where we can feed two birds with one slice of bread using Linux Signals.

The signal I use personally is SIGTERM -- which indicates intent to terminate the process. This signal is sent by the operating service when the client container is going to be shutdown. While you can catch this signal and prevent shutdown, most of services will send a SIGKILL signal forcing shutdown of the app after a certain time duration. In some cases this is configurable.

We feed two birds because using SIGTERM an app can:

execute clean up code
gracefully shutdown the application

This ensures that any operations an app is in the middle of, have some time to exit. So what does that look like?

// javascript
process.on('SIGTERM', () => {
    console.info('SIGTERM signal received.');

    /**
     * This is where cleanup code can be run. For example, closing down the http server.
     */
    console.log('Closing http server.');
    server.close(() => {
        console.log('Http server closed.');
    });

    process.exit(0)
});

This example snippet runs in a nodejs environment, attaching an anonymous function () => {...} to the process when SIGTERM signal occurs. The clean up code will run and the server which is an http server in this example, but could be any service time, is closed, and process.exit(0) is fired.

Note: Exit code 0 means the process exited successfully, any other exit code indicates an error of some type.

App Platform: Handling GitLab submodules

Jon Friesen — Mon, 05 Apr 2021 00:00:00 +0000

Git submodules are a bit of a pain; that said we are iterating on this and trying to make it better in the future. I do have a workaround that will hopefully handle your needs:

This assumes that your submodule is hosted in the same account/team as your app repository.

When an app is created from a GitLab project, we create and assign a deploy key to that project. Our build system uses that deploy key to check out the repository code as well as all submodule repositories. This means we need to enable that deploy key on the submodules repository.

Get the deploy key UUID from the app repository by going to the project, then

1. Settings
2. Repository
3. Deploy Keys
4. Copy the deploy key name (it’s a UUID)
5. then go to the submodule repository, and

1. Settings
2. Repository
3. Deploy Keys
4. Privately accessible deploy keys
5. Search for the deploy key matching the UUID copied from the above
   step and click Enable.

You will also need to use the git ssh URL instead of the git https url in your .gitmodules file. So git@gitlab.com:owner/repo.git instead of https://gitlab.com/owner/repo.git.

App Platform: How to set an app timezone?

Jon Friesen — Tue, 16 Mar 2021 00:00:00 +0000

Apps that run on and built by App Platform use a fairly standard Linux container environment. This means that lots of standard linux configurations work on apps.

To set the timezone of an app, set the TZ environment variable, this can be as simple as:

TZ='Africa/Lagos'

Or using more complex timezone configurations.

App Platform: Injecting files from Environment Variables

Jon Friesen — Wed, 03 Mar 2021 00:00:00 +0000

App Platform apps (that don't use dockerfiles) are built using Cloud Native Build Packs, which turn your code into a OCI image that is run on a secured, shared Kubernetes instance. App Platform offers the ability to apply environment variables to your app, in many cases app secrets are stored in these env vars, and in less common cases the apps require these secrets to exist as a file on the filesystem.

Some options to make this happen are:

Commit the secret to the app git repository so it's present when the build occurs.
- The obvious drawback here is that the secret is in the git and the git history. This is unacceptable in most cases.
Convert the App to use a dockerfile and echo the environment variable to disk with the dockerfile.
- Slightly better than the first option, this method still persists your secret to the OCI image.
Finally, explicitly take over the run command and inject the file at run time.
- This method does not persist the secret anywhere in an unencrypted fashion.
- It ensure that the right version of your secret is present.
- The drawback is it your app run_command needs to be manually set.

How do we do this?

1. Add the environment variable to your app and check the Encrypt checkbox.

2. Select the component that requires the secret and Edit the Commands to look something like

echo "${APP_CERT}" > jwt.cer && <your_apps_run_command>

In this snippet, the APP_CERT environment variable writen to a file called jwt.cer and then the apps execution code is ran.

Further Considerations

In some cases you may need to encode your file before saving it as an environment variable, which will require decoding it.

Encoding your file using base64

The base64 tool comes with Linux and MacOS by default, getting a base64 representation of your file can be down with:

cat <your_file> | base64

this also means your file will need to be decoded before being written to disk. Update your run command to:

echo "${APP_CERT}" | base64 --decode > jwt.cer && <your_apps_run_command>

App Platform: How to set specific NodeJS version?

Jon Friesen — Wed, 21 Oct 2020 00:00:00 +0000

NodeJS projects have an optional configuration in their package.json for indicating the supported engine(s) for an app. This can look like:

{ 
  "engines" : { 
    "node" : "12.19.0" 
  }
}

ranges are also supported, for example:

{ 
  "engines" : { 
    "node" : ">=12.0.0 <=14.0.0" 
  }
}

this range says an app can be run on NodeJS 12 to 14 (inclusively).

Click here for more info on NoedJS engines.

DEV Community: Jon Friesen

Review: Learn Concurrent Programming with Go

How to create GitHub Actions test summaries for Go

Full Workflow Sample:

Go Explored: new() vs make()

The new() function

Example

The make() function

Example

Instantiating

new()

make()

Conclusion

Docker in Docker access for non-root users

App Platform: Automatically deploy pre-built container images on push

How autodeploy works

Enabling autodeploy

UI: During creation

UI: Exising image components

App Spec: Enabling within the spec

An GitHub Actions example

Adding middleware to Go HTTP client requests

App Platform: Hosting static NextJS projects

NextJS configurations

App Platform configurations

Handling container shutdowns in app code

Further reading

App Platform: Handling GitLab submodules

App Platform: How to set an app timezone?

App Platform: Injecting files from Environment Variables

Some options to make this happen are:

How do we do this?

Further Considerations

Encoding your file using base64

App Platform: How to set specific NodeJS version?

The `new()` function

The `make()` function

`new()`

`make()`