I understand that these things happen and it is out of our control, however, one thing I strive for is transparency. I want to know who was affected so I can assist them or at least provide some of time and provide moral support.

By default, Slack Workspaces allow any member to install apps, so your self-created app can usually be installed in that workspace. However, Workspace Owners/Admins can turn on app approval and other restrictions; in that case, your app may need explicit admin approval before install, or might be blocked entirely. You will need to be able to install a slack app to proceed.

In this post I’ll show you a small Python CLI that talks to the Slack API through Slack’s official WebClient, lists all deactivated accounts, lets you filter by last activity date, and prints everything as a clean table. Use this knowledge and application your own risk.

How Slack represents deactivated users

Slack doesn’t really “delete” people when they’re laid off. Their account is deactivated, their profile can be scrubbed, and admins can choose what to retain, but from the API’s perspective, they’re still part of the user list.

When you call users.list via the Slack Web API using the official Python client, you get every user in your workspace, including those with a deleted flag set to true. That flag is your signal that the account is no longer active. With the right scopes, you can also see profile fields like email addresses and, via other methods, the last time Slack saw any activity from that user.

Put simply: the raw ingredients to understand “who disappeared and roughly when” are already there. You just need a small tool to pull them together.

The CLI: slack-deactivated-users

Instead of building a web app and wiring up a database, the simplest workflow is a command you can run in your terminal whenever you want a snapshot.

The CLI does three things:

• Uses Slack underlying WebClient to call Slack’s users.list API and fetch every user in your workspace.
• Filters down to those marked as deleted/deactivated.
• Optionally looks up each user’s last activity timestamp (where available), applies any date filters you provided, and prints a nicely formatted table.

At a high level, the main command looks like this:

• slack-deactivated-users --from-date 2026-01-01 Show deactivated user the from the date range.
• slack-deactivated-users --from-date 2026-01-01 --to-date 2026-03-31
  Show deactivated users whose last activity falls in that date range.

This is done with a direct conversation between your terminal and Slack.

Setting it up in your own workspace

To get this working, you’ll need a basic understanding of Slack and python. We will start by creating a Slack app and obtaining a token, which we will then use to scrape slack for deactivate users with the CLiI

Create a Slack app and get a token

1. Visit https://app.slack.com and login
2. Visit https://api.slack.com/apps
3. Press the Create New App button and select From scratch
4. Provide the app with a Name and select your Workspace and press the Create App button, you’ll be transported to the App settings page

5. Select OAuth & Permissions in the side-tab and scroll down to Scopes and add the following to Bot Token Scopes:

• users:read
• users:read.email (to see email addresses)

6. Select in Install App the side-tab and continue with the instructions to install the app into your workspace.

7. You will obtain a Bot User OAuth Token, keep it someplace safe, it will be used when running the CLI application.

Install the CLI application

You can clone the CLI application and then just run it in a python virtual environment and install it on your system.

# Clone the repository
git clone https://gitlab.com/fern-inc/slack-deactivation-tracker-cli
cd slack-deactivated-users

# Install in a virtual environment
python3 -m venv .venv
source .venv/bin/activate
pip install .

Run the CLI application

If an admin were to deactivate a user, as seen in this image:

then when running the following command, you’ll see the user was deactivated. Note: Information has been omitted for privacy reasons.

# Export the SLACK_TOKEN as an env variable
export SLACK_TOKEN=<YOUR_TOKEN_HERE>
slack-deactivated-users --from-date 2026-04-01

 Deactivated Slack Users                                      
┏━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━┓
┃ User ID     ┃ Name          ┃ Email                   ┃ Bot?  ┃ Last Activity        ┃ Deleted? ┃
┡━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━┩
│ U085XXXXXXX │ XXXXX XXXXXX  │ xxxxxxxxxxxxx@gmail.com │ Human │ 2026-04-04 20:16 UTC │ Yes      │
└─────────────┴───────────────┴─────────────────────────┴───────┴──────────────────────┴──────────┘

If you get permission errors or empty fields where you expect data, double-check your app’s scopes and the plan-level features around presence and user data.

Additionally, checkout all the possible commands by reading the README.md in https://gitlab.com/fern-inc/slack-deactivation-tracker-cli for example, you can check who is new to slack from a particular date:

$ slack-deactivated-users --from-date 2026-01-01 --active

What you can learn (and what you can’t)

This CLI gives you a fast way to answer questions like:

• “How many people were deactivated around the time of that ‘small restructuring’ email?”
• “Were there multiple waves of deactivations over the last quarter?”
• “When was the last time that deactivated coworker actually appeared active in Slack?”

The answers will never be perfect. Some deactivations are just contractors rolling off, access clean-ups, or testing. Last activity timestamps might be missing or imprecise, and Slack’s presence APIs have their own quirks and limitations depending on your plan. And there’s always a delay between when HR makes a decision and when IT flips the switch in Slack.

But when you’re living through a chaotic layoff cycle, even an approximate view of who disappeared and when can be a lot better than refreshing your channels and guessing.

Ethics, privacy, and self‑protection

As with any tool that touches people data, it’s important to think about how you use it.

• You’re not discovering secret data
  The CLI surfaces information that Slack already provides through its SDK layer and Web API methods, including the fact that some users are deactivated and, in some cases, when they were last active. It’s a convenience layer, not a backdoor.
• Treat the output as sensitive
  A text file listing deactivated colleagues is essentially a layoff ledger. Store it securely, limit who sees it, and avoid posting it in public Slack channels or external social media.
• Remember what Slack can see
  Separate from this CLI, Slack and workspace admins have broad visibility into user activity and, on higher-tier plans, can export messages, logs, and other data. If you need to talk about layoffs, toxic leadership, or organizing with coworkers, consider using channels that are not owned and logged by your employer.

Used thoughtfully, a little CLI like this can turn a vague sense of dread “it feels like a lot of people are disappearing” into concrete information you can use to make decisions about your own path.

With that being said, according to the Nautilus 2022 Cloud Native Threat report, threat actors broadened their targets to include CI/CD environments and vulnerable Kubernetes deployments and applications.

Over time the amount and types of attacks targeting Kubernetes environments has continued to increase. Based on attacks that AquaSec observed, the number of malicious images with the potential to target Kubernetes environments increased by 10% from 2020 (9%) to 2021 (19%). This is why it’s more important than ever to secure your GoLang application!

In this blog post, I will show different ways to scan your application source code for vulnerabilities, as well as how to integrate security scanners into a CI/CD platform like GitLab. I will provide real-world examples with an insecure microservice I have created.

Prerequisites

• Basic understanding of the Go programming language
• Basic knowledge of Git
• Basic understanding of application security
• GitLab account (Free)
• Go version 1.19+ (I used the below)

$ go version

go version go1.19.1 darwin/amd64

Security Scanners

By running security scanners before pushing code, we can detect and remediate vulnerabilities before we deploy our code to a production-level environment. I will go over how to use a variety of different security scanners for Go such as GoSec, GoVulnCheck, and Fuzz.

First we can start by setting up a proper GOPATH, adding GOPATH/bin to our PATH, and cloning the insecure microservice. Additional information on paths can be found here.

# Set the appropriate GOPATH
$ export GOPATH=/path/to/your/go/projects

# Add your GOPATH bin directory to your PATH
$ export PATH=$PATH:$GOPATH/bin

# Go into your GOPATH
$ cd $GOPATH

# Create the proper directory structure
$ mkdir -p src/gitlab.com/awkwardferny

# Clone application which we will be scanning
$ git clone git@gitlab.com:awkwardferny/insecure-microservice.git src/gitlab.com/awkwardferny/insecure-microservice

# Go into the application root
$ cd src/gitlab.com/awkwardferny/insecure-microservice

Now that we have the paths correctly setup and the application has been cloned, we can start running our security scanners!

GoSec (Source Code Analysis)

The first security scanner we will cover is GoSec. It is a popular Go security scanner which scans your application’s source code and dependencies for vulnerabilities. It works by pattern matching your source code against a set of rules.

GoSec will also automatically scan your application dependencies for vulnerabilities if the go module is turned on (e.g.GO111MODULE=on) or if you explicitly download the dependencies (go get -d). Now let’s run GoSec on our insecure microservice:

# Install GoSec
$ go install github.com/securego/gosec/v2/cmd/gosec@latest

# Run GoSec
$ gosec ./...

After the scanner has run we can take a look at the vulnerabilities we found:

G404 (CWE-338): Use of weak random number generator (math/rand instead of crypto/rand) (Confidence: MEDIUM, Severity: HIGH)

G114 (CWE): Use of net/http serve function that has no support for setting timeouts (Confidence: HIGH, Severity: MEDIUM)

G104 (CWE-703): Errors unhandled. (Confidence: HIGH, Severity: LOW)

G104 (CWE-703): Errors unhandled. (Confidence: HIGH, Severity: LOW)

G104 (CWE-703): Errors unhandled. (Confidence: HIGH, Severity: LOW)

G104 (CWE-703): Errors unhandled. (Confidence: HIGH, Severity: LOW)

These vulnerabilities show that our application has many uncaught exceptions, is not setting timeouts, and uses a weak random number generator. The scan returns the Rule Triggered, Common Weakness Enumeration(CWE), Confidence, Severity, and the Affected Line of Code (Not Pictured).

In a typical developer workflow, after vulnerabilities are found, the developer can examine the CWE for tips on remediation, make code changes to the affected line(s) of code, and then re-run the scanner to check for resolution. Regression tests should be run to make sure our application logic is still sound.

Govulncheck (Source Code Analysis)

Next up is Govulncheck! Govulncheck is a security scanner for source code and application dependencies. It is under active development by the Go security team and is different than GoSec in a few ways:

First it is backed by the Go vulnerability database.

Second it only displays vulnerabilities which your code is actually calling. This reduces noise and lets you know what vulnerabilities actually affect your application.

Below is the architecture diagram for Govulncheck, showing its datasources, the vulnerability database, tools, and integrations.

Now let’s give it a spin! ⚙️

# Install govulncheck
$ go install golang.org/x/vuln/cmd/govulncheck@latest

# Run govulncheck
$ govulncheck ./...

After the scanner has run, let’s take a look at its findings:

Vulnerability #1: GO-2020-0016

An attacker can construct a series of bytes such that calling Reader. Read on the bytes could cause an infinite loop. If
parsing user supplied input, this may be used as a denial of service vector.

Call stacks in your code:

internal/logic/logic.go:63:8: gitlab.com/awkwardferny/insecure-microservice/internal/logic.insecure calls github.com/ulikunitz/xz.Reader.Read

Found in: github.com/ulikunitz/xz@v0.5.7
Fixed in: github.com/ulikunitz/xz@v0.5.8
More info: https://pkg.go.dev/vuln/GO-2020-0016

You can see that the scanners presents us with a Vulnerability Rule Reference, Description, Affected Line of Code, Vulnerable Dependency, Resolution, and a Link to Additional Info.

Because I’m using github.com/ulikunitz/xz@v0.5.7 as a dependency in my application and calling xz.Reader.Read, my application is vulnerable to DDoS attacks. This vulnerability was detected by the GO-2020–016 rule from the Go vulnerability database.

In a typical workflow, a developer would update the dependency version and then rerun the scanner as well as unit and functional tests in order to ensure the application does not break.

Fuzz (Fuzz-Testing)

And last we are going to go over fuzz testing. Fuzz testing is the practice of inputing random/malformed data into an application in an attempt to reveal security issues or bugs. Go has a native fuzzing library called fuzz.

Fuzz performs coverage-based fuzz tests which are written similar to unit-tests and are performed on application functions. They are good at finding edge-cases/bugs you may miss in your own unit-tests. Let’s look at this fuzz test example below:

func FuzzAdd(f *testing.F) {
  f.Add("1", "2")
  f.Fuzz(func(t *testing.T, a string, b string) {
    result, err := add(a, b)
    if err != nil {
      t.Errorf(fmt.Sprintf("error: %v", err))
    }

    intA, _ := strconv.Atoi(a)
    intB, _ := strconv.Atoi(b)
    expected := intA + intB

    if result != expected {
      t.Errorf(fmt.Sprintf("expected %v, got %v", expected, result))
    }
  })
}

func add(a string, b string) (c int, e error) {
  intA, err := strconv.Atoi(a)
  if err != nil {
    return 0, nil
  }

  intB, err := strconv.Atoi(b)
  if err != nil {
    return 0, nil
  }

  return (intA + intB), nil
}

We can see that FuzzAdd() is written similar to a unit test. We enable fuzz testing by adding f.Fuzz(func(t *testing.T, a string, b string), which calls the add(a string, b string) function, supplying random data for variables a and b. Then it compares the result against the expected value.

The add() function, simply converts 2 strings into integers and then adds them up and returns the result.

The FuzzAdd() test runs correctly with the seeded dataf.Add("1", “2”),but what happens when there’s malformed or random data? Let’s run our fuzz test and find out:

# Run the fuzz tests
$ go test ./internal/logic -fuzz FuzzAdd

We can see that the scanner detected an error:

--- FAIL: FuzzAdd (0.10s)
    --- FAIL: FuzzAdd (0.00s)
        logic_test.go:44: expected 1, got 0
    
    Failing input written to testdata/fuzz/FuzzAdd/9f4dc959af0a73c061c4b4185e9fdb9e5dbfc854cccce7bf9199f0f5556c42a9
    To re-run:
    go test -run=FuzzAdd/9f4dc959af0a73c061c4b4185e9fdb9e5dbfc854cccce7bf9199f0f5556c42a9
FAIL

This error was caused because an actual letter (A) was passed instead of a string that can be converted into an integer. Fuzz also generated a seed corpus under the testdata directory, which can be used to test this particular failure again.

An idea to resolve this would be to simply return err instead of nil in the add() function and expect the error for non-integer convertible strings in FuzzAdd().

We can also consider just making the integer value a 0 and logging the error as seen below. It Just depends on what we are trying to achieve.

func add(a string, b string) (c int, e error) {
  intA, err := strconv.Atoi(a)
  if err != nil {
    // change value to 0 if error is thrown
    intA = 0
    // TODO: Log the error (err)  
  }

intB, err := strconv.Atoi(b)
  if err != nil {
    // change value to 0 if error is thrown
    intB = 0
    // TODO: Log the error (err)
  }

  return (intA + intB), nil
}

For more advanced usage of fuzz, checkout the Go fuzz-testing tutorial.

Automation of Scanners with GitLab

Running the security scanners to search for vulnerabilities in your Go application can be automated so that we can run the scanners on a feature branch each time code is pushed.

This allows us to address security issues before we push code into production and saves us time by not having to run the scanners manually each time we make a code change.

These scanners can be automated by creating a CI/CD pipeline in GitLab 🦊. The pipeline can automatically run these scans on each code push to any branch. We will be looking at the GitLab CI yaml, which generates a CI/CD pipeline below.

First thing we see are the stages which will run within the pipeline in the order provided:

stages:
  - build
  - test

The build stage makes sure the application even builds before proceeding. If you’ve containerized your application, in this stage you would ideally also test if a container image can be built as well:

build:
  image: golang:alpine
  stage: build
  script:
    - go mod download
    - go build .

Then the test stage will run unit-tests, fuzz-tests, as well as the security scanners described in this blog. The appropriate dependencies for running these jobs are also installed.

We can see under fuzz, that we have an artifact directive with a path that runs whenever the job fails. This is done so that we can download the seed corpus to run locally:

unit:
  image: golang:alpine
  stage: test
  script:
    - apk update
    - apk add g++ git
    - go test -v ./...

gosec:
  image: golang:alpine
  stage: test
  script:
    - apk update
    - apk add g++ git
    - go install github.com/securego/gosec/v2/cmd/gosec@latest
    - gosec ./...

go-vuln-check:
  image: golang:alpine
  stage: test
  script:
    - apk update
    - apk add g++ git
    - go install golang.org/x/vuln/cmd/govulncheck@latest
    - govulncheck ./...

fuzz:
  image: golang:alpine
  stage: test
  script:
    - apk update
    - apk add g++ git
    - go test ./internal/logic -fuzz FuzzAdd -fuzztime 50s
  artifacts:
    paths:
      - internal/logic/testdata/*
    when: on_failure

All the above described in the GitLab CI yaml, generates the following pipeline where we can see fuzz, gosec, and govulncheck all fail, showing there are vulnerabilities and bugs detected within our code:

If we click on a test we can see the output of our job. For example when clicking on the govulncheck job, we see the following:

And that is how you can integrate unit-tests, fuzz-tests and security scanners into your CI/CD pipeline. This makes life way easier and removes the need for running everything manually each time!

Code Reviews and Secure Coding Practices

Last, but not least, in order to enhance application security, you should always perform code reviews. This is crucial because others can find issues that you may miss. Scanners may find vulnerabilities, but they cannot detect incorrect logic.

Secure Coding Practices are provided by the Open Web Application Security Project (OWASP). These practices should be reviewed in order to provide great feedback on enhancing security within a code review.

Some examples of these Secure Coding Practices include Database Security, Output Encoding, Error Handling and Logging, and much more.

Other Considerations

Separation of duties

Another way to reduce insecure code from making it to production is to enforce separation of duties. Separation of duties is the concept where developers should only have access to the functions which are necessary for their job. Some examples of this would be:

• Don’t allow developers to merge their own commits
• Require security team or team-lead approval if a vulnerability is found
• Don’t allow security scans to be disabled by developers
• Implement CODEOWNERS functionality

Other attack vectors

There are other aspects of an application which can be susceptible to attack which are not part of the application source code. Some examples of this include:

• Container images
• Application dependencies in other languages
• Restrictive licenses
• Configurations within the running application/server

These items can be remedied with additional security scanners as well as implementing security policies and providing reviews around configurations. I use GitLab Ultimate security policies and scanners for my day-to-day.

Visibility into security posture

Another thing to consider is how great your visibility into your application’s security posture is. You should have insight on which projects have the most concerning vulnerabilities and what is being done about them.

A dashboard type of view would be ideal, that way you can effectively triage and manage vulnerabilities, guiding you to what you should be address first.

And there you have it, Go 🐿 application security and AppSec automation made easy! Thanks for reading and I hope you enjoyed this article.

If you want to see similar articles like this, checkout my other stories and do share this with others! Also feel free to find me on twitter 🐦, my posts consist of travel, philosophy, tech, comedy, and some cool things I find.

At GitLab we have a development director shadow program which allows any GitLab employee a deeper look into the day-to-day operations of an engineering director.

Last year I had the opportunity to be part of GitLab’s CEO shadow program. I got tremendous value out of it, and learned what CEO’s do and how they operate. This year, I went ahead and signed up to shadow Wayne Haber, our engineering director for growth, security, and data science. This experience has provided me more insight on how another part of GitLab operates.

In this program I was exposed to most of Wayne’s meetings in order to learn what an engineering director does, how they do it, and how they make decisions. Exploring more leadership positions has given me perspective on what my growth path should be.

Starting the program

I learned about the program by posts on the slack channel for the Secure stage development team. My experience started with an introduction call the week before, where I prepared for the program by:

• Obtaining access to Wayne’s calendar
• Going over what is expected of the program
• Discuss what Wayne is currently working on

Notable Meetings

As an engineering manager shadow I attended many of Wayne’s zoom meetings in order to gain perspective of his day-to-day.

The below are some of the notable meetings I attended:

InfraDev/Engineering Allocation

In this meeting a variety of different VPs and engineering managers discussed error budgets, reliability, and security.

The SLA requirements, security issues, and corrective actions were discussed. We went over what issues are currently affecting our error budgets and must be remediated. Root causes were analyzed and then a plan was made for remediation.

This has shown me the efficiency of having all the information on a single document and then discussing proposals to correct. This makes the meeting flow much easier than not having any data beforehand.

Anti-Abuse Planning

In this meeting, I gained insight on limits that should be set in order to alert when we believe abuse has been performed on the system. Then we can examine illegitimate usage from free accounts.

I was able to learn how abuse is detected, and what we are doing to detect the new innovative ways in which malicious actors try to obtain free compute for crypto mining from our system.

Product Meeting

In this meeting, Wayne happened to be a guest speaker introducing himself and his responsibilities, counterparts, and top priorities. It was nice to understand his biggest challenges after almost 3 years at GitLab and how he handled them.

Notable Merge Requests (MRs)

I assisted with reviewing a number of merge requests and issues. Wayne would send me a few each day to show what he has been working on, so that I can provide feedback.

Going through these issues allowed me to prepare for meetings and have a deeper understanding as to what is going on in the organization.

Engineering Internship Working Group

This MR contained information on starting a new working group for our engineering internship. I provided my thoughts on the process for establishing a working group, and what information should be provided in the handbook.

ModelOps has been renamed to DataScience and Anti-Abuse has been moved in

This MR showed me that some development teams were being renamed for others to better understand their purpose. ModelOps maybe a confusing name, but data-science is very clear.

Anti-Abuse was moved under DataScience since it analyzes patterns in the data in order to determine abuse.

Preventing Abuse

In this MR, I was able to gain some insight as to how we identify and continue to advance abuse prevention of GitLab pipelines.

This is a problem in many companies, due to users taking advantage of free runner cycles for cryptocurrency mining.

Issues with Logging In

This MR was a reported issue on certain browsers and plugins not causing errors in the GitLab login process. Although uncommon, there were still occurrences, so it is important to investigate.

I suggested in each failed login we record the browser, add-ons, and OS version, so that we can test compatibility and keep metrics on what browsers experience issues.

Conclusion

On the last day of the shadow program, I met with Wayne to discuss what I have learned and ways we can improve the program. I went ahead and suggested the following:

• Director should continue to report a list of merge requests and issues of interest daily — This provides the shadow with something to work on and look into each day aside from meetings

I really enjoyed my time as an engineer shadow and will continue to seek guidance from Wayne! I got to see aspects of the company I would have never seen without going through this program.

Thanks for reading, I hope you enjoyed this article! If you want to see similar articles like this, checkout my other stories.

Feel free to find me on twitter 🐦, My posts consist of travel, philosophy, tech, comedy, and some cool things I find.

There are many cool server applications we can create which interact with Kubernetes using client-go. Sometimes we want to make our applications visually appealing, so that we can easily perform functions without the need to send requests via curl, postman, etc.

In this blog post, I’ll go over how to add a Web UI to a Kubernetes application. I will be building upon Secreto-Server which can be seen in detail in my previous blog post Build, Test, and Automate a Kubernetes Interfacing Application in Go. It’s recommended that you read that blog before proceeding.

We’ll be going over the Secreto-Client which allows for the following functions to be provided via a web UI:

• Creating a Kubernetes Secret
• Viewing all Kubernetes Secrets
• Describing a Kubernetes Secret
• Deleting a Kubernetes Secret

These actions can be performed in the following ways:

Creating a Secret

By clicking on the ✚ button, we can see a dialog popup with a form used for inputting data in order to create a secret.

Viewing all Secrets

All secrets are displayed in cards as soon as the application is run.

Describing a Secret

A secret can be described in more detail by clicking on the button.

Deleting a Secret

A secret can be deleted by clicking the ❌ button.

The Secreto-Client generates a UI and then sends requests to the Secreto-Server based on the action performed.

Prerequisites

We will be building both a server and a client. The server code is written in Go and has its own requirements, the client is code written in ReactJS.

• React-JS: A JavaScript library for building user interfaces. React-JS makes it easy for us to build a user interface knowing minimal nodeJS.
• Go: An open-source programming language supported by Google
• MiniKube: a tool that quickly sets up a local Kubernetes cluster on macOS, Linux, and Windows. You will also need a virtualization driver for MiniKube to run such as Docker, HyperV, Podman, etc. More information can be found here. You can use other types of clusters (Docker Desktop Kubernetes, GKE, AKS, etc.), I’m using Minikube because it’s easily accessible.
• Kubernetes Knowledge: You should know a bit about Kubernetes to understand the purpose of the application.

Let’s make sure that Minikube is running before we proceed. We can do this by running the following command:

$ minikube start

😄  minikube v1.25.2 on Darwin 12.3 (arm64)
✨  Using the podman (experimental) driver based on existing profile
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
E0321 11:05:07.616563   66007 cache.go:203] Error downloading kic artifacts:  not yet implemented, see issue #8426
🔄  Restarting existing podman container for "minikube" ...
🐳  Preparing Kubernetes v1.23.3 on Docker 20.10.12 ...E0321 11:05:13.251398   66007 start.go:126] Unable to get host IP: RoutableHostIPFromInside is currently only implemented for linux
▪ kubelet.housekeeping-interval=5m
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
💡  kubectl not found. If you need it, try: 'minikube kubectl -- get pods -A'
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

Now let’s make sure the minikube node is ready.

$ minikube kubectl get nodes

NAME       STATUS   ROLES                  AGE     VERSION
minikube   Ready    control-plane,master   3m50s   v1.23.3

Loading the Secreto Server

The backend can be loaded the following way:

1. Clone the application to your GOPATH

$ git clone git@gitlab.com:k2511/secreto-server.git

git clone git@gitlab.com:k2511/secreto-server.git
Cloning into 'secreto-server'...
remote: Enumerating objects: 235, done.
remote: Counting objects: 100% (232/232), done.
remote: Compressing objects: 100% (121/121), done.
remote: Total 235 (delta 97), reused 177 (delta 69), pack-reused 3
Receiving objects: 100% (235/235), 282.99 KiB | 3.11 MiB/s, done.
Resolving deltas: 100% (97/97), done.

$ cd secreto-server

2. Build the application executable

I created a Makefile which makes it easy. Once this command is run, there should be a new executable created named secreto-server.

$ make build

go mod download
GOOS=darwin GOARCH=arm64 go build -o secreto-server .
chmod +x secreto-server

Note: You may need to change $GOOS and $GOARCH variables in the Makefile if you aren’t running on an M1 Mac. More details here.

3. Run the application locally

This is done by just passing the -local flag when running the executable. Running it without the -local flag, would require the application to be running in the Kubernetes cluster because it uses a different auth method.

$ ./secreto-server -local

2022/03/20 16:18:30 KubeClient running with local configuration
2022/03/20 16:18:30 Starting server on the port 8080

You can also change the port by setting the SECRETO_PORT environment variable before executing the program.

Now the application is running. Let’s go ahead and confirm it’s working. We can do this by opening up another terminal and sending a request to the server to obtain its version.

$ curl http://localhost:8080/api/secreto/version

{"version":1}

We now have a working server! Now let’s go ahead and deploy the client.

Loading the Secreto Client

The client can be loaded the following way:

1. Clone the Repository

$ git clone git@gitlab.com:k2511/secreto-client.git

Cloning into 'secreto-client'...
remote: Enumerating objects: 109, done.
remote: Total 109 (delta 0), reused 0 (delta 0), pack-reused 109
Receiving objects: 100% (109/109), 6.20 MiB | 5.46 MiB/s, done.
Resolving deltas: 100% (58/58), done.

2. Download Dependencies

$ npm install --silent
$ npm install react-scripts -g --silent

3. Run the application

$ npm start

Compiled successfully!

You can now view client in the browser.

  Local:            http://localhost:3000/
  On Your Network:  http://192.168.3.7:3000/

Note that the development build is not optimized.
To create a production build, use npm run build.

You should now see the following screen when visiting the application page, localhost:3000:

Note: The secrets displayed on your screen may very. I have been messing around with my Minikube cluster, so it looks a little different for me.

If you’d like to run the application on a different port, simply set the environment variable PORT to the port you’d like to run on, for example:

$ PORT=3001 npm start

Compiled successfully!

You can now view client in the browser.

Local:            http://localhost:3001/
  On Your Network:  http://192.168.86.24:3001/

Note that the development build is not optimized.
To create a production build, use npm run build.

Creating Visuals with Semantic-UI

Semantic-UI made it really simple for me to get started creating a minimalistic and visually appealing page. Semantic is a development framework that helps create beautiful, responsive layouts using human-friendly HTML.

An example would be generating a popup would be as follows which is the form for creating a secret. Notice the following:

• Popup is defined using readable HTML
• Popups can be triggered by clicking on an Icon, this is seen by the trigger being the icon and the popup loading on a click
• Content, which is what is displayed within the popup can point towards a function that can load more layouts. In the case of this popup, we are loading a form to input data for generating a new secret.

<Popup        
  trigger={
    <Icon 
       circular name='add'
       color='grey'
     />
   }
               
   content={() => this.renderSubmitForm()}
   size='large'
   on='click'
   position='bottom center'>
</Popup>

Semantic has so many different types of objects with so many different configurations. I suggest giving their documentation a look.

Sending Requests with Axios

Axios is another great tool which aided me in building this interface. Axios is a promise-based HTTP Client for node.js and the browser. I used it in order to send requests to the secreto-server based on the actions taken in the ReactJs Semantic UI.

An example of using Axios is as follows seem below shows the following:

• Variables from the state are grabbed, which are populated by what is input into the form used for generating secrets
• Axios sends a post to a global endpoint I have defined. It uses data (namespace) grabbed from the state in order to populate the rest of the URI
• A body is passed as the 2nd parameter, containing the name and payload of the secret
• Headers are passed as a 3rd parameter
• We log response and reload the secrets which now contain the new secret we just generated

    createSecret = () => {
      const {name, namespace, payload} = this.state
      
      axios.post(this.endpoint + "/api/secreto/" + namespace,
        {
          "name": name, 
          "payload": payload
        },
        {
          headers: {
            "Content-Type": "application/x-www-form-urlencoded",
          },
        },
        ).then(res => {
          console.log(res);
          this.getSecrets();
      })
    }

And there you have it, Minimalist UI for a Kubernetes interfacing application. Feel free to examine the source code for both projects and dive in!

Thanks for reading, and I hope this blog can get you started with adding a cool minimalist UI to your web-server.

Want to Connect?

You can find me on twitter @awkwardferny

Adding a Minimalistic ReactJS UI to Your Kubernetes Application was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kubernetes’ Client-Go provides all sorts of packages for interacting with your cluster. These packages include the following:

• The kubernetes package contains the clientset to access Kubernetes API.
• The discovery package is used to discover APIs supported by a Kubernetes API server.
• The dynamic package contains a dynamic client that can perform generic operations on arbitrary Kubernetes API objects.
• The plugin/pkg/client/auth packages contain optional authentication plugins for obtaining credentials from external sources.
• The transport package is used to set up auth and start a connection.
• The tools/cache package is useful for writing controllers.

Along with all the above packages, Client-Go also contains a fake client, which allows you to mockup the creation, reading, editing, and removal of a particular Kubernetes resource in order to easily increase unit-test coverage.

Back in KubeCon Europe 2019, I presented on performing unit tests using the Go-Client fake client:

Today, I’d like to go over creating a simple out-of-cluster application used to perform actions on your Kubernetes cluster. Then I’ll show you how to mock out the Kubernetes API calls in your unit tests, and automate running these tests and more with GitLab!

Prerequisites

In order to get started, there are a few programs you must have installed:

• Go— an open source programming language.
• MiniKube— a tool that quickly sets up a local Kubernetes cluster on macOS, Linux, and Windows. You will also need a virtualization driver for MiniKube to run such as Docker, HyperV, Podman, etc. More information can be found here.

Note: You can use another cluster other than minikube, and it’ll work just fine based on the kubectl context which is set. This guide is written using minikube, because it’s accessible to everyone.

You must also have knowledge of the following:

• Go Basics — The code I have written and will go over is in Go. Make sure you have a basic understanding.
• Kubernetes Basics — Understand how to work with Kubernetes clusters, and using kubectl.
• Kubernetes Secrets — Understand what secrets are in Kubernetes.

It is good to know the following:

• Git Basics — Good to know Git to create forks and make modifications to the code yourself.
• GitLab CI— My code is housed in GitLab, and I am using the GitLab CI in order to run my unit tests and security scans.

I will be using my secreto-server project which performs the following functions:

• Generates generic Kubernetes secrets
• Lists the secrets per a given namespace
• Obtains secret data which includes the payload
• Deletes secrets

Running the Application (Locally)

To start off, we’ll create a cluster using MiniKube and make sure we can interact with Kubernetes secrets. Then we will launch the application locally and verify all the application’s functions.

Creating Kubernetes Cluster

1. Install MiniKube.You’ll be able to download a version of Minikube based on your OS and Architecture on the Getting Started Page.

2. Run Minikube. It may take a few minutes to download the required packages, but running Minikube is straightforward as long as you have the required virtualization drivers. Docker Desktop works for most, but I’m using podman to try something different. See the Minikube documentation for more information on drivers.

$ minikube start

minikube v1.25.2 on Darwin 12.3 (arm64)
Using the podman (experimental) driver based on existing profile
Starting control plane node minikube in cluster minikube
Pulling base image ...
E0321 11:05:07.616563   66007 cache.go:203] Error downloading kic artifacts:  not yet implemented, see issue #8426
Restarting existing podman container for "minikube" ...
Preparing Kubernetes v1.23.3 on Docker 20.10.12 ...E0321 11:05:13.251398   66007 start.go:126] Unable to get host IP: RoutableHostIPFromInside is currently only implemented for linux
▪ kubelet.housekeeping-interval=5m
Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
Enabled addons: storage-provisioner, default-storageclass
kubectl not found. If you need it, try: 'minikube kubectl -- get pods -A'
Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

3. Verify that Minikube is running correctly. We can do this by checking if the Minikube node has a STATUS of ready.

$ minikube kubectl get nodes

NAME       STATUS   ROLES                  AGE     VERSION
minikube   Ready    control-plane,master   3m50s   v1.23.3

4. Create a secret. We will do this through kubectl just to verify that we have access to the secrets API. I’m creating a generic secret with the literal[shhh]=supersecret .

$ minikube kubectl create secret generic my-secret -- --from-literal=shhh=supersecret

secret/my-secret created

5. Now, let’s verify that the secret was created successfully

We can grab it in YAML mode and see the base64 encoded supersecret (c3VwZXJzZWNyZXQ=).

$ minikube kubectl get secrets my-secret -- -o yaml

minikube kubectl get secrets my-secret -- -o yaml
apiVersion: v1
data:
  shhh: c3VwZXJzZWNyZXQ=
kind: Secret
metadata:
  creationTimestamp: "2022-03-20T21:16:48Z"
  name: my-secret
  namespace: default
  resourceVersion: "728"
  uid: 9fcb7814-77f1-44dc-b476-066db11598bd
type: Opaque

Building the Application

1. Clone the application to your GOPATH

$ git clone git@gitlab.com:k2511/secreto-server.git

git clone git@gitlab.com:k2511/secreto-server.git
Cloning into 'secreto-server'...
remote: Enumerating objects: 235, done.
remote: Counting objects: 100% (232/232), done.
remote: Compressing objects: 100% (121/121), done.
remote: Total 235 (delta 97), reused 177 (delta 69), pack-reused 3
Receiving objects: 100% (235/235), 282.99 KiB | 3.11 MiB/s, done.
Resolving deltas: 100% (97/97), done.

$ cd secreto-server

2. Build the application executable. I created a Makefile which makes it easy. Once this command is run, there should be a new executable created named secreto-server.

$ make build

go mod download
GOOS=darwin GOARCH=arm64 go build -o secreto-server .
chmod +x secreto-server

Note: You may need to change $GOOS and $GOARCH variables in the Makefile if you aren’t running on an M1 Mac. More details here.

3. Run the application locally. This is done by just passing the -local flag when running the executable. Running it without the -local flag, would require the application to be running in the Kubernetes cluster because it uses a different auth method.

$ ./secreto-server -local

2022/03/20 16:18:30 KubeClient running with local configuration
2022/03/20 16:18:30 Starting server on the port 8080

You can also change the port by setting the SECRETO_PORT environment variable before executing the program.

Now the application is running. Let’s go ahead and confirm it’s working. We can do this by opening up another terminal and sending a request to the server to obtain its version.

$ curl http://localhost:8080/api/secreto/version

{"version":1}

We now have a working application! Let’s verify several of the application’s functions.

Adding a secret

We can add a secret by passing a name and payload to the secreto API path. Make sure you also add the namespace to the end of the path as seen below.

$ curl -X POST http://localhost:8080/api/secreto/default -d '{"name": "my-secret2", "payload": "my-secret-yoo"}'

{"Secret Created Successfully":{"name":"my-secret2","namespace":"default","date":"2022-03-20 17:39:41 -0500 CDT","payload":"my-secret-yoo"}}

Viewing secrets

We can list all of our secrets, sort by namespace, and even look up the payload. This is done by performing a GET on different paths:

• /api/secreto: lists all secrets
• /api/secreto/{namespace}: lists all secrets in {namespace}
• /api/secreto/{namespace}/{name}: lists data for secret {name} in {namespace}

$ curl -X GET http://localhost:8080/api/secreto

[{"name":"default-token-m9wsq","namespace":"default","date":"2022-03-20 16:10:27 -0500 CDT","payload":""},{"name":"my-secret","namespace":"default","date":"2022-03-20 16:16:48 -0500 CDT","payload":"supersecret"},{"name":"yeet","namespace":"default","date":"2022-03-20 16:56:24 -0500 CDT","payload":"my-secret-yoo"},{"name":"default-token-dq5wr","namespace":"kube-node-lease","date":"2022-03-20 16:10:26 -0500 CDT","payload":""},{"name":"default-token-nwbxx","namespace":"kube-public","date":"2022-03-20 16:10:26 -0500 CDT","payload":""},{"name":"attachdetach-controller-token-cdfl4","namespace":"kube-system","date":"2022-03-20 16:10:14 -0500 CDT","payload":""},{"name":"bootstrap-signer-token-ljx9n","namespace":"kube-system","date":"2022-03-20 16:10:14 -0500 CDT","payload":""},{"name":"bootstrap-token-81dbvo","namespace":"kube-system","date":"2022-03-20 16:10:13 -0500 CDT","payload":""},{"name":"certificate-controller-token-9nqdf","namespace":"kube-system","date":"2022-03-20 16:10:15 -0500 CDT","payload":""},{"name":"clusterrole-aggregation-controller-token-wb95r","namespace":"kube-system","date":"2022-03-20 16:10:13 -0500 CDT","payload":""},{"name":"coredns-token-7sldt","namespace":"kube-system","date":"2022-03-20 16:10:14 -0500 CDT","payload":""},{"name":"cronjob-controller-token-l5msx","namespace":"kube-system","date":"2022-03-20 16:10:16 -0500 CDT","payload":""},{"name":"daemon-set-controller-token-ppr8p","namespace":"kube-system","date":"2022-03-20 16:10:16 -0500 CDT","payload":""},{"name":"default-token-mxzhs","namespace":"kube-system","date":"2022-03-20 16:10:26 -0500 CDT","payload":""},{"name":"deployment-controller-token-ctsrt","namespace":"kube-system","date":"2022-03-20 16:10:13 -0500 CDT","payload":""},{"name":"disruption-controller-token-kf9qs","namespace":"kube-system","date":"2022-03-20 16:10:14 -0500 CDT","payload":""},{"name":"endpoint-controller-token-kkp5b","namespace":"kube-system","date":"2022-03-20 16:10:13 -0500 CDT","payload":""},{"name":"endpointslice-controller-token-b4bwk","namespace":"kube-system","date":"2022-03-20 16:10:13 -0500 CDT","payload":""},{"name":"endpointslicemirroring-controller-token-g7bqq","namespace":"kube-system","date":"2022-03-20 16:10:15 -0500 CDT","payload":""},{"name":"ephemeral-volume-controller-token-t7s6h","namespace":"kube-system","date":"2022-03-20 16:10:14 -0500 CDT","payload":""},{"name":"expand-controller-token-wvhn8","namespace":"kube-system","date":"2022-03-20 16:10:26 -0500 CDT","payload":""},{"name":"generic-garbage-collector-token-q62cw","namespace":"kube-system","date":"2022-03-20 16:10:26 -0500 CDT","payload":""},{"name":"horizontal-pod-autoscaler-token-wmkcc","namespace":"kube-system","date":"2022-03-20 16:10:13 -0500 CDT","payload":""},{"name":"job-controller-token-9492p","namespace":"kube-system","date":"2022-03-20 16:10:26 -0500 CDT","payload":""},{"name":"kube-proxy-token-6z9ht","namespace":"kube-system","date":"2022-03-20 16:10:14 -0500 CDT","payload":""},{"name":"namespace-controller-token-lrwx8","namespace":"kube-system","date":"2022-03-20 16:10:15 -0500 CDT","payload":""},{"name":"node-controller-token-x9vwn","namespace":"kube-system","date":"2022-03-20 16:10:16 -0500 CDT","payload":""},{"name":"persistent-volume-binder-token-vdw68","namespace":"kube-system","date":"2022-03-20 16:10:26 -0500 CDT","payload":""},{"name":"pod-garbage-collector-token-jl9z2","namespace":"kube-system","date":"2022-03-20 16:10:16 -0500 CDT","payload":""},{"name":"pv-protection-controller-token-jv9d8","namespace":"kube-system","date":"2022-03-20 16:10:13 -0500 CDT","payload":""},{"name":"pvc-protection-controller-token-d4ccm","namespace":"kube-system","date":"2022-03-20 16:10:13 -0500 CDT","payload":""},{"name":"replicaset-controller-token-hbdj6","namespace":"kube-system","date":"2022-03-20 16:10:15 -0500 CDT","payload":""},{"name":"replication-controller-token-74kl8","namespace":"kube-system","date":"2022-03-20 16:10:13 -0500 CDT","payload":""},{"name":"resourcequota-controller-token-767r2","namespace":"kube-system","date":"2022-03-20 16:10:13 -0500 CDT","payload":""},{"name":"root-ca-cert-publisher-token-7zbhn","namespace":"kube-system","date":"2022-03-20 16:10:14 -0500 CDT","payload":""},{"name":"service-account-controller-token-vdxgt","namespace":"kube-system","date":"2022-03-20 16:10:26 -0500 CDT","payload":""},{"name":"service-controller-token-nvt8n","namespace":"kube-system","date":"2022-03-20 16:10:15 -0500 CDT","payload":""},{"name":"statefulset-controller-token-97d8r","namespace":"kube-system","date":"2022-03-20 16:10:26 -0500 CDT","payload":""},{"name":"storage-provisioner-token-nsblb","namespace":"kube-system","date":"2022-03-20 16:10:16 -0500 CDT","payload":""},{"name":"token-cleaner-token-wdbdn","namespace":"kube-system","date":"2022-03-20 16:10:15 -0500 CDT","payload":""},{"name":"ttl-after-finished-controller-token-rgjt4","namespace":"kube-system","date":"2022-03-20 16:10:16 -0500 CDT","payload":""},{"name":"ttl-controller-token-tzjfc","namespace":"kube-system","date":"2022-03-20 16:10:14 -0500 CDT","payload":""}]

$ curl -X GET http://localhost:8080/api/secreto/default

[{"name":"default-token-m9wsq","namespace":"default","date":"2022-03-20 16:10:27 -0500 CDT","payload":""},{"name":"my-secret","namespace":"default","date":"2022-03-20 16:16:48 -0500 CDT","payload":"supersecret"},{"name":"my-secret2","namespace":"default","date":"2022-03-20 16:56:24 -0500 CDT","payload":"my-secret-yoo"}]

$ curl -X GET http://localhost:8080/api/secreto/default/my-secret

{"name":"my-secret","namespace":"default","date":"2022-03-20 16:16:48 -0500 CDT","payload":"supersecret"}

Deleting secrets

Now, let’s go ahead and delete a secret we created earlier. This is done by performing a DELETE on the full path of a secret.

$ curl -X DELETE http://localhost:8080/api/secreto/default/my-secret

{"Secret Deleted Successfully":"my-secret"}

Analyzing the Code

Now let’s dive into the application code. I’m primarily going to go over the parts which interact with the Kubernetes API. The application is split up in the following way:

• middleware: Contains all the application logic for processing a request and generating a response. This includes communicating with the Kubernetes API in order to perform different functions on secrets.
• router: Routes calls from particular URIs to the application logic in the middleware.
• model: Contains structs that are used in the application to display and create secrets.
• main.go: Starts the application, loading the web-server.

Now let’s take a dive into how the source code works.

Authentication and setup

Authenticating with a Kubernetes client can be seen in middleware.go. In this article, we will be going over out-of-cluster authentication.

This code was taken from the out-of-cluster config example of Client-Go. The main parts to notice are:

• The Kubernetes config is set by looking at what’s active in the ~/.kube/config folder
• If no home directory exists, then we must pass -kubeconfig along with the path of our Kubernetes configuration in order for it to load properly
• There is a global variable ClientSet=client set so that we don’t need to keep loading the kubeconfig and can just run commands with the ClientSet

Adding a secret

In order to add a secret, the code below accepts a request, calls the private createSecret function, and then returns the response to the user. The main parts to notice are:

• Sets headers for CORS, for example, Access-Control-Allow-Methods which will allow browsers to use different types of methods
• Grabs parameters for the namespace from the URI route {namespace} defined in router.go
• Generates a Kubernetes API call based on the items in the request body
• Encodes either the actual secret and returns it, or returns an error

The code below is a private function that uses Client-Go in order to create a secret. The main parts to notice are:

• metav1.ObjectMeta is setup along with the secret payload which is encapsulated in the maps secretData and secretDataBytes
• A Kubernetes v1.Secret based on the data sent in the function is passed to the Kubernetes API for the creation of the secret
• If the generation of the secret is successful then we generate a Secreto object and fill it with data from the secret before returning it

Viewing a secret

We have several functions used to view secrets. They grab Kubernetes' secrets and their info using Client-Go. I’m just going to go over obtaining the secret details since most functions are similar. The main parts to notice are:

• Sets headers for CORS, for example, Access-Control-Allow-Methods which will allow browsers to use different types of methods
• Grabs parameters for the namespace and name from the URI route {namespace}/{name} defined in router.go, and generates a call to the Kubernetes API
• Encodes either the actual secret and returns it, or returns an error

The code below is a private function that uses Client-Go in order to describe a secret obtaining its details with Client-Go.

func getSecretDetails(namespace string, name string) (*v1.Secret, error) {
	secret, err := ClientSet.CoreV1().Secrets(namespace).Get(context.TODO(), name, metav1.GetOptions{})

	if err != nil {
		return nil, err
	}

	return secret, nil
}

Deleting a secret

Deleting a secret is pretty straightforward. The main parts to notice are:

• Sets headers for CORS, for example, Access-Control-Allow-Methods which will allow browsers to use different types of methods
• Grabs parameters for the namespace and name from the URI route {namespace}/{name} defined in router.go, and generates a call to the Kubernetes API
• Returns a message saying that the secret was successfully deleted, or returns an error

The code below is a private function that uses Client-Go in order to delete a secret:

func deleteSecret(name string, namespace string) error {
	err := ClientSet.CoreV1().Secrets(namespace).Delete(context.TODO(), name, metav1.DeleteOptions{})
	if err != nil {
		return err
	}

	return nil
}

Writing Unit Tests

Now that we have seen all the different functions within the application, we are gonna go ahead and write some unit tests. Unit tests are individual tests on different parts of our application, which are important for verifying our logic and making sure our application is doing what it should.

All the unit tests I have written are located in middleware_test.go.

General setup

I created a function that just sets up test values for the different unit tests. You can see the setupSecrets() function which will generate different secrets as well as expected values to look for.

Mocking Client-Go

ClientSet is a global variable defined in middleware.go. Within the tests, we overwrite it, allowing all the requests to return fake values without communicating to our Kubernetes cluster. The fake client makes requests returning mock objects and values.

ClientSet = fake.NewSimpleClientset()

Mocking requests

Requests can be mocked using httptest, which provides utilities for HTTP testing and allows us to “record” requests. A few things to notice are:

• A request is created and test variables are passed in the requestBody
• The CreateSecret function is called with the fake w http.ResponseWriter, r *http.Request that we generated

Running tests

Now that we’ve gone over the tests, we can go ahead and run them. This can be done by running the following command:

$ make test

go test -v ./...
?    gitlab.com/k2511/kube-secreto [no test files]
=== RUN   TestProcessSecrets
--- PASS: TestProcessSecrets (0.00s)
=== RUN   TestGetSecretsClient
--- PASS: TestGetSecretsClient (0.00s)
=== RUN   TestGetSecretDetailsClient
--- PASS: TestGetSecretDetailsClient (0.00s)
=== RUN   TestCreateSecretClient
--- PASS: TestCreateSecretClient (0.00s)
=== RUN   TestDeleteSecretClient
--- PASS: TestDeleteSecretClient (0.00s)
=== RUN   TestGetSecretsByNamespace
--- PASS: TestGetSecretsByNamespace (0.00s)
=== RUN   TestGetSecretDetails
--- PASS: TestGetSecretDetails (0.00s)
=== RUN   TestCreateSecret
--- PASS: TestCreateSecret (0.00s)
=== RUN   TestDeleteSecret
--- PASS: TestDeleteSecret (0.00s)
=== RUN   TestGetVersion
--- PASS: TestGetVersion (0.00s)
PASS
ok   gitlab.com/k2511/kube-secreto/internal/server/middleware 1.406s
?    gitlab.com/k2511/kube-secreto/internal/server/models [no test files]
?    gitlab.com/k2511/kube-secreto/internal/server/router [no test files]

Automating Testing With Coverage and Sast

I am using GitLab for CI to automate building, testing, and pushing the application container to my registry. This makes it so that I don’t have to manually perform these functions each time I push code.

I can configure GitLab so that my application is automatically tested so I can verify my application logic. My application is also built, containerized, and pushed to my container registry. I can also check if my source code is secure using GitLab SAST.

My GitLab Yaml looks as follows:

Now, if we look at the newest running GitLab Pipeline, we can see the following:

• Build stage: runs build which builds the application and docker-build which builds the application container and pushes it to my container registry
• Test stage: unit runs unit tests and generates a coverage report, gosec-sast and semgrep-sast uses gosec and semgrep respectively to scan the application source code for vulnerabilities

When clicking on the Security tab, we can see a few vulnerabilities we should resolve, sorted by severity.

Clicking on one provides a description, location, CVE, and solution. You can also dismiss the vulnerability or create a confidential issue to work on remediation with others without alerting those without permission.

There’s also more security scanners you can look into as well as other cool CICD tools at GitLab.

Thanks for reading, and I hope this article can get you started with creating and testing an application that interacts with Kubernetes!

Build, Test, and Automate a Kubernetes Interfacing Application in Go was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are times in my life when I am feeling down and depressed. I can’t find meaning in life, but I keep on and pushed myself towards a better life.

I very much believe that we are the creators of our own happiness and if we want, we do what it takes to attain it, but we need goals and meaning. We also need to be able to endure what life throws at us, since there will always be ups and downs.

“Don’t take my word for it, go ahead and watch these videos”

Live life like you are the hero in your own story — Joe Rogan

Joe Rogan is a is an American podcaster, UFC color commentator, comedian, actor, and former television presenter. You may have seen him on Fear Factor, or listened to his podcast.

The main points I take from this video are:

• Pretend you are the protagonist in the start of a movie where your life is a total disaster. Then progress through the movie (your life) making steps to become the hero. Get out of bed, do the dishes, clean up the house, workout, get out there and solve the problems that have been haunting you.
• Write down your goals and what you need to do to attain them. Then make small progressive steps towards those goals. I like to add these steps to a calendar, in order to see my progression.
• Doing difficult things lessens the stress of regular life. Don’t fear the difficult, they will make you stronger. You’ll know the situation when it comes up again, and know you survived and will again.
• If you feel bad about how you have acted in the past, realize that you are not the same person, you are the person that has learned and can handle the situation better the next time. You have changed and are different person, a better person.

Have a Vision — Arnold Schwarzenegger

Arnold Schwarzenegger is is an Austrian-American actor, former bodybuilder, film producer, businessman, and former politician who served as the 38th governor of California from 2003 to 2011. As of 2021, he is the most recent Republican governor of California.

The main points I take from this video are:

• You need vision and goals. If you don’t have these you will aimlessly drift around in an unhappy life. You need a purpose in life to really be happy.
• Work your ass off. If you are passionate about something and want to see it come to fruition, you must put in the work to make it reality. Nothing just falls in your lap, you need to do the work.
• Imagine if you put 1 hour into anything. After 365 hours of reading, working out, etc. you will grow tremendously. You will regret the time spent idle.
• Don’t fear failure, we all fail. What you need is to be persistent and keep trying to achieve.

Don’t Give Up — Jordan Peterson

Jordan Peterson is is a Canadian professor of psychology, clinical psychologist, YouTube personality, and author.

The main points I take from this video are:

• Life can be meaningful enough to justify it’s suffering. Life isn’t made to be happy all the time, but for you to find meaning, and be on the right path. You need to figure out what gives you meaning.
• You need goals, and when you are depressed you may feel like you don’t have any. Act like you do, and hang on to something. Start with small goals and build up. For example, getting out of bed and eating healthy can be a goal.
• Face small problems you know are there. Don’t let them become bigger problems. An unpaid bill that you fear looking at will only increase if you don’t take care of it. Don’t let depression make your problems bigger and contribute to more depression.
• Believe in yourself. Treat yourself how you treat a person you really love. You need to be kind to yourself and believe in all the potential within you. You are necessary to more than you think, what you do matters, so respect yourself.

Thanks for Reading!

I hope these motivation videos inspire you and help you get on a better path in life. I have found lots of these resources through the Mulligan Brothers. They have an amazing compilation of motivation videos.

Debugging is an important part of resolving programming problems. There are many tools out there that are much better than print statements, although this is a debated topic.

Python comes with a built-in interactive debugger known as pdb.

Pdb allows you to set breakpoints and single step at the source line level, inspect stack frames, list source code, and evaluate arbitrary Python code in the context of any stack frame. Post-mortem debugging can also be performed under program control.

Then there’s rpdb, a remote debugger based on pdb. It re-routes stdin and stdout to a socket handler, so that you can debug server processes.

When do I use pdb over rpdb?

Pdb should be used in local applications, whereas rpdb runs remotely and can be used to debug web frameworks like Flask. With rpdb installed, you can start the server and run through the server code remotely.

Below I’ll show you both pdb and rpdb running in some simple applications, one which is running as a script, and one which starts a Flask server. Be sure to clone the Debugging in Python Repo to run the examples in this tutorial.

$ git clone https://github.com/diazjf/learn-pydebug

Cloning into 'learn-pydebug'...
remote: Enumerating objects: 18, done.
remote: Counting objects: 100% (18/18), done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 18 (delta 0), reused 15 (delta 0), pack-reused 0
Receiving objects: 100% (18/18), 103.60 KiB | 573.00 KiB/s, done.

$ cd learn-pydebug

Note: The Debugging in Python Repo has information on installing and running applications which include and show off pdb and rpdb. The code has comments on where the issue is and how debugging can help.

Using pdb

We add the following code to where in the application we want to start pdb. The code in pdb/main.py contains the following line:

import pdb; pdb.set_trace()

When running the python application, pdb will automatically start when that pdb.set_trace() is hit.

$ python pdb/main.py
Enter some words: I am a cat

> /Users/fernandodiaz/Desktop/debugging/pdb/main.py(23)<module>()
-> num_chars = count(input)
(Pdb)

you’ll see that pdb is initiated. Pdb contains the following basic functions, which can be run at the prompt. Here are some examples of the output from pdb after some commands are run.

• l(ist): Lists the lines surrounding the current line

(Pdb) l

18       input = input("Enter some words: ")
19
20       import pdb; pdb.set_trace()
21
22       # count the number if characters
23  ->     num_chars = count(input)
24       print("Number of Characters: %s" % num_chars)

• w(here): Displays the file and line number where we currently are

(Pdb) w

> /Users/fernandodiaz/Desktop/learn-pydebug/pdb/main.py(23)<module>()
-> num_chars = count(input)

• s(tep): Step into the function at the current line

(Pdb) s

--Call--
> /Users/fernandodiaz/Desktop/learn-pydebug/pdb/main.py(3)count()
-> def count(message=""):

• n(ext): Execute the current line

(Pdb) n

> /Users/fernandodiaz/Desktop/learn-pydebug/pdb/main.py(4)count()
-> msg = message.split()

• a(rgs): Print the argument list of the current function

(Pdb) a

message = 'I am a cat'

• p(rint) <name>: Print value of <name>

(Pdb) n

> /Users/fernandodiaz/Desktop/learn-pydebug/pdb/main.py(9)count()
-> if len(msg) > 3:

(Pdb) p msg

['I', 'am', 'a', 'cat']

Note: I ran all these commands in order on the pdb testing application.

By running these commands we can continue to go to the next lines in the count function until we see something wrong. In this example we can see that

if len(msg) > 3: 
  return “TOO MANY WORDS, TRY AGAIN”

This shows is that we either need to add more details to the message to let users know what is acceptable or we can adjust the number of words to be number of chars instead. No matter how we solve it, we can now tell where the issue is.

Although it may not seem that impressive here, pdb is really useful in large codebases where there is alot going on.

Using rpdb

We add the following to where in the application we want to start rpdb:

import rpdb; rpdb.set_trace()

Note: rpdb must be installed for this command to be recognized. It is installed in the prerequisites.

If you take a look at rpdp/remote/routes.py, you can see that the debugger was added to the /count route. We can run the Flask web-server by installing the prerequisites and then running:

$ python rpdb/run.py

* Serving Flask app 'remote' (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: on
 * Running on all addresses.
   WARNING: This is a development server. Do not use it in a production deployment.
 * Running on http://192.168.1.147:5000/ (Press CTRL+C to quit)
 * Restarting with stat
 * Debugger is active!
 * Debugger PIN: 926-264-267

In a separate terminal we can send a request to the endpoint the application is running on.

$ curl -X POST http://192.168.1.147:5000/count -d '{"message": "This is a message"}'

Here we are sending a message that originally caused the server to throw a 400. With the debugger present, this request causes the application to hang and allows us to go through the debugger and see what’s going on. We can do this by running the following in a separate terminal:

$ nc 127.0.0.1 4444

> /Users/fernandodiaz/Desktop/debugging/rpdb/remote/routes.py(15)add_note()
-> if not msg:
(Pdb)

Now we can run commands just like we did with pdb in order to determine why we get 400s with our message.

This tutorial provides the basics. There are other ways of using these debuggers, as well as more commands, which can be seen in the pdb and rpdb documentation.

Thanks for reading, and I hope you enjoyed! For more content, and to keep up with what I write, follow me on twitter🐦

Debugging your code in Python — pdb vs. rpdb was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

In an age where companies like Netflix are running over 500 Microservices at once, it is important to quickly find out where exactly a failure or decrease in performance is coming from. It can be like finding a slightly discolored piece of hay in a haystack, unless something like Distributed Tracing is in place.

Distributed Tracing is a way of profiling and monitoring applications. It can pinpoint the location of failures and slowdowns, helping you debug and optimize your code.

This post will provide a tutorial on getting Distributed Tracing working from ingress-nginx to your microservice functions. We will be using Meow-Micro 🐈, as the tutorial application, which was created for this very blog post.

Prerequisites

• Knowledge of GoLang
• Knowledge of Kubernetes
• Knowledge of Ingress-NGINX
• Docker-Desktop
• Helm v3

This guide assumes that you can understand code written in Go and know how to use ingress-nginx and understand how basic Kubernetes objects such as services and deployments work.

If you want a refresher, you can checkout the following resources:

• Kubernetes Basics
• Ingress-Nginx Basics

Docker Desktop and Installing Ingress-Nginx

Now let’s install Docker Desktop, which is used for the building and sharing of containerized applications and microservices as well as running Kubernetes locally. Once you have installed Docker Desktop, go through the following steps to enable Kubernetes.

1. Click on the Preferences Icon

2. Select the Kubernetes tab, Check the Enable Kubernetes button, and click the Apply & Restart button

3. Press the Install button, and wait for the installation to complete

4. In the menu bar select Kubernetes

5. In the context select docker-desktop

6. Open the terminal and confirm you are using the correct cluster

$ kubectl cluster-info

Kubernetes master is running at https://kubernetes.docker.internal:6443
KubeDNS is running at https://kubernetes.docker.internal:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Installing Ingress-Nginx

1. Now we can install Ingress-Nginx simply by running the following command as seen in the Ingress-Nginx Getting Started Guide

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.45.0/deploy/static/provider/cloud/deploy.yaml

namespace/ingress-nginx created
serviceaccount/ingress-nginx created
configmap/ingress-nginx-controller created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
service/ingress-nginx-controller-admission created
service/ingress-nginx-controller created\
deployment.apps/ingress-nginx-controller created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created
serviceaccount/ingress-nginx-admission created]
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
job.batch/ingress-nginx-admission-create created\
job.batch/ingress-nginx-admission-patch created

2. We can confirm the installation by checking if the ingress-nginx-controller pod is ready and running successfully

$ kubectl get pods -n ingress-nginx

NAME                                     READY   STATUS    RESTARTS 

ingress-nginx-admission-create-52jsl        0/1     Completed   0          
ingress-nginx-admission-patch-78fkc         0/1     Completed   0          
ingress-nginx-controller-6f5454cbfb-qsfnn   1/1     Running     0          

Note: If there are memory/cpu issues, you may need to increase your resources

Installing Jaeger and configuring the Ingress Controller

Jaeger is a distributed tracing platform, which we will use to monitor our microservices. Now let’s install Jaeger and enable tracing at the ingress-controller level.

1. Start by cloning meow-micro, the project which we will be using for this tutorial

$ git clone https://github.com/diazjf/meow-micro.git

Cloning into 'meow-micro'...
remote: Enumerating objects: 105, done.
...

$ cd meow-micro

2. We then need to install Jaeger. I created an updated yaml for jaeger-all-in-one which can be applied as follows

$ kubectl apply -f jaeger/jaeger-all-in-one.yaml

deployment.apps/jaeger created
service/jaeger-query created
service/jaeger-collector created
service/jaeger-agent created
service/zipkin created

3. Confirm that jaeger is running and ready

$ kubectl get pods

NAME                      READY   STATUS    RESTARTS   AGE
jaeger-6f6b5d8689-8gccp   1/1     Running   0          17s

4. Now to enable communication between ingress-nginx and jaeger, we need to add the enable-opentracing and jaeger-collector-host keys to the ingress-nginx-controller configmap.

This tells the ingress controller to send traces to jaeger at the given endpoint, which is defined by the jaeger-agent service

$ echo '
  apiVersion: v1
  kind: ConfigMap
  data:
    enable-opentracing: "true"
    jaeger-collector-host: jaeger-agent.default.svc.cluster.local              
  metadata:
    name: ingress-nginx-controller
    namespace: ingress-nginx
  ' | kubectl replace -f -

configmap/ingress-nginx-controller replaced

5. Confirm that the Ingress Controller has opentracing enabled and is correctly setup

$ kubectl get pods -n ingress-nginx | grep controller

ingress-nginx-controller-6f5454cbfb-qptxt   1/1     Running     0          8m56s

$ kubectl exec -it ingress-nginx-controller-6f5454cbfb-qptxt -n ingress-nginx -- bash -c "cat nginx.conf | grep ngx_http_opentracing_module.so"

load_module /etc/nginx/modules/ngx_http_opentracing_module.so;

$ kubectl exec -it ingress-nginx-controller-6f5454cbfb-qptxt -n ingress-nginx -- bash -c "cat nginx.conf | grep jaeger"

opentracing_load_tracer /usr/local/lib/libjaegertracing_plugin.so /etc/nginx/opentracing.json;

$ kubectl exec -it ingress-nginx-controller-6f5454cbfb-qptxt -n ingress-nginx -- bash -c "cat /etc/nginx/opentracing.json"

{
  "service_name": "nginx",
  "propagation_format": "jaeger",
  "sampler": {
    "type": "const",
    "param": 1,
    "samplingServerURL": "http://127.0.0.1:5778/sampling"
  },
  "reporter": {
    "endpoint": "",
    "localAgentHostPort": "jaeger-agent.default.svc.cluster.local:6831"
  },
  "headers": {
    "TraceContextHeaderName": "",
    "jaegerDebugHeader": "",
    "jaegerBaggageHeader": "",
    "traceBaggageHeaderPrefix": ""
  }
}

Now we have both jaeger and ingress running on our cluster. We can then deploy our microservices!

Deploy Microservices with Instrumentation

Instrumentation is added to our microservices to extract important information about the microservices. Instrumentation is required for us to be able to perform traces and map out specific functions.

In this section we will deploy 2 different Microservices from our sample project meow-micro 🐈 which contain the OpenTracing Instrumentation. The meow-client microservice will accept a REST call and send the information to the meow-server microservice via GRPC.

For a refresh on REST and GRPC with GoLang see:

• GoLang HTTP Server
• GoLang GRPC Communication

Now let’s go over some of the files which instrumentation was added to.

tracing.go

Contains the information for configuring the Jaeger tracer. It grabs the configuration values from the environment, which are set in the helm templates for meow-client and meow-server.

cfg, err := config.FromEnv()
if err != nil {
panic(fmt.Sprintf("Could not parse Jaeger env vars: %s", err.Error())) 
}  

tracer, closer, err := cfg.NewTracer()
if err != nil {  
 panic(fmt.Sprintf("Could not initialize jaeger tracer: %s", err.Error())) 
}

client.go

In the client, we setup the service name for the trace(a data/execution path through the system, and can be thought of as a directed acyclic graph of spans) to be meow-client.

We also setup the span (a logical unit of work in Jaeger that has an operation name, the start time of the operation, and the duration) to start when the main function is called, as well as when the sleep function is called. This will let us know how long sleep took within main, since there is a span for each one.

// main function span
os.Setenv("JAEGER_SERVICE_NAME", "meow-client")
tracer, closer := tracing.Init()
defer closer.Close()

http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {

spanCtx, _ := tracer.Extract(opentracing.HTTPHeaders, opentracing.HTTPHeadersCarrier(r.Header))
span := tracer.StartSpan("send-meow-communication", ext.RPCServerOption(spanCtx))
defer span.Finish()

...

// sleep function span
os.Setenv("JAEGER_SERVICE_NAME", "meow-client")
tracer, closer := tracing.Init()
defer closer.Close()

span := tracer.StartSpan("sleep")
defer span.Finish()

Installing the microservices

Now let’s go ahead and deploy the microservices into our cluster. Make sure you have helm v3 installed, I installed mine using brew.

$ brew install helm
...
==> Downloading https://ghcr.io/v2/homebrew/core/helm/manifests/3.5.4
######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/helm/blobs/sha256:5dac5803c1ad2db3a91b0928fc472aaf80a4
==> Downloading from https://pkg-containers-az.githubusercontent.com/ghcr1/blobs/sha256:5dac5803c1ad2db
######################################################################## 100.0%
==> Pouring helm--3.5.4.big_sur.bottle.tar.gz
...

$ helm version
version.BuildInfo{Version:"v3.3.4", GitCommit:"a61ce5633af99708171414353ed49547cf05013d", GitTreeState:"clean", GoVersion:"go1.14.9"}

Now let’s deploy these microservices onto our Kubernetes Cluster using the Makefile.

# Build client and server from Dockerfile
$ make build

docker build -t meow-client:1.0 -f client/Dockerfile .
[+] Building 17.1s (10/10) FINISHED
...
docker build -t meow-server:1.0 -f server/Dockerfile .
[+] Building 0.5s (10/10) FINISHED
...

# Install Microservices into Kubernetes via Helm
$ make install

helm install -f helm/Values.yaml meow-micro ./helm
NAME: meow-micro
LAST DEPLOYED: Mon Apr 26 13:42:38 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

We can verify that everything is working by making sure the pods are running and ready.

$ kubectl get pods

NAME                           READY   STATUS    RESTARTS   AGE
jaeger-6f6b5d8689-s7cln        1/1     Running   0          26m
meow-client-8b974778c-85896    1/1     Running   0          15m
meow-server-56f559db44-5mvgp   1/1     Running   0          15m

Viewing the Trace

Now for the exciting part! Taking a look at a trace.

1. Let’s open up the Jaeger console, by pointing our browser to http://localhost:8081. This is where we have the jaeger UI running. You should see a cool interface as follows

2. Now let’s send a request to our application, so that the trace can be logged

$ curl http://localhost/meow -X POST -d '{"name": "Meow-Mixer"}'

200 - Meow sent: Meow-Mixer

3. Now refresh your browser and you should see populated tabs. We can select nginx as the service

4. Then press the Find Traces button

5. Now you should see all the traces for nginx, we can expand by clicking anywhere in the trace item

6. You can see how long each function took, from the call to nginx(ingress) ➡️ main(client) ➡️ sleep(client). This gives us information on how long we were stuck in each span. We see that we were a whole 2 out of 3 seconds in the sleep, telling us it should be something to examine.

This is a cool little example to get you started, but you see the real power of tracing when you add this to several functions across your microservices.

You can further expand an operation in the trace to obtain more information

7. Here we can see more info on the sleep function

Other Tracers and Configurations

Currently Zipkin, Jaeger, and DataDog are supported for Distributed Tracing with Ingress-Nginx.

These different Distributed Tracing items in Ingress-Nginx that can be further configured for the supported Tracers. These can be found in the Ingress-Nginx documentation.

Hope you enjoyed this blog post! For more information on Distributed Tracing, be sure to checkout the Jaeger Documentation which contains lots of cool resources.

Also be sure to checkout my Medium profile for more content like this and feel free to follow @awkwardferny on Twitter.

I’ve been making lots of videos for marketing technical features for my employer (GitLab). In this guide I will show you how to make great videos that will not only draw, but keep users attention.

Disclaimer, I’m not at influencer level yet! Keyword “yet”.

I’ll go over the following topics:

• Script Planning 📄
• Gear 📹
• Video Editing + Screen Recording 📼
• Thumbnails 💅
• Titles and Descriptions 🛤
• Pattern Interrupts 👽
• Cards and End Screens 📩
• Promoting on Social Media 🐦

Here is a video I have created, so you can see the type of content I create:

Script Planning and Value Highlighting

Your videos should be very well thought out before you actually get into the process of recording. I like to use the screenplay format for everything I write. It helps me keep my mind organized. It’s good to have a starting point, and later the flow can be improved during the film process.

Another tip that is helpful for me is to create a character which the audience can relate to. This makes the video more interesting and more likely to keep the audience engaged. I include a mix of video (with you in it), screen-recordings, audio, and stock photos in the production.

It’s also important for technical videos to note that you should try not to be too markety. If you are just selling a product, it tends to dis-interest a viewer, especially a developer (I know from experience). Make the video as generic as possible to the technical subject, but show the value of your product as well.

Once everything is thought out, it should be recorded as it was described in the script, making edits here and there before it is put together. For example this script was used in order to make the DevSecOps Overview video.

Gear

The quality of your video and audio is important to how long a viewer will be engaged.

For video-recording I would recommend one of the following:

• DSLR Camera capable of 4K
• iPhone XR or better
• Android capable of 4K video

Nowadays, most smartphones are capable of delivering high-quality video. I would try to aim for 30fps 4K recording or better.

For audio-recording I would recommend the following:

• Lapel Microphone
• Shotgun Microphone for DSLR or Shotgun Microphone for phone
• Yeti microphone (for recording voice-overs)

Other equipment you will need:

• Laptop capable of video editing (I have a MacBook Pro)
• Tripod
• Carrying bags
• Lighting Equipment
• 101 Things I learned in Film School (Good easy to follow book, I recommend)

Don’t worry about getting all these things at once, they are just what I use to try and make videos as professional as possible.

You can start small and just record video using yourself phone, record the technical content on your computer screen using a free screen-recording tool, and then editing with some free video editing software.

Video Editing

After recording exactly what you will be showcasing, we get to the editing. The recording should be how it was planned on the script with improvisation where needed.

We must make sure to have recorded multiple takes and some b-roll. Multiple takes are important, because you don’t want to have to go back to filming when you are in editing mode.

When all your footage is complete, we can now begin the editing process. Here are a few things to consider when editing:

• Cropping: You should crop out any irrelevant content. Many times I see sooooooooo many tabs open on others screen recordings.
• Voice-Over: You should maintain the same tone throughout the video. Outside noise should also be reduced.
• Cuts: If you said certain things like “ummmm” in a video and it would take too much time to re-record everything, simply perform a cut. The transition not being smooth is not necessarily a bad thing (see interrupt below)
• Zooming: Try and zoom in when showing a particular workflow

For Screen Recording I would recommend any of the following:

• Zoom (start a meeting, record, and screen-share)
• Quicktime Player
• Camtasia
• OBS: Open Broadcaster Software

For Video Editing I would recommend any of the following:

• iMovie
• Adobe Premiere Pro
• Final Cut Pro
• Davinci Resolve

Each has its own pros and cons, and different people like different tools. For the type of videos I make, I find Final Cut Pro to be the best for me.

Pattern Interrupts

In video marketing and filmmaking, pattern interrupts are tiny clips or on-screen elements who break the projection of the viewer for what is about to happen in the video they’re watching -wildfireconcepts

Adding pattern interrupts to videos makes sure that there are enough changes in your video to keep users engaged. There are a few things you can do to create these interrupts:

• Adding Popups and Sounds throughout the video
• Adding Stock Photos within the video
• Zooming into different parts of the video
• Completely changing the location of the video (example: moving from live video to recorded demo)

Thumbnails

Thumbnails are an important part of grabbing a viewers attention. With so many videos on YouTube, we tend to click on the ones with an image that grasps our interest.

Be sure to include the following in your thumbnail:

• An image with something related to the content
• Text giving some context about the video

Youtube provides a great guide to making thumbnails which captivate an audience. Over time I’m getting better and better at making these. One improvement that can be done on the above is making the font larger.

I use Adobe Spark which makes it easy to generate not only thumbnails for YouTube, but also promotional material for Social Media, which we will discuss later.

Titles and Descriptions

Titles are crucial not only to having your content appear on searches, but also towards getting users to actually click on the video. Make sure your title is not only well-written, but that it is true to your content. You want users to come back to your page and not be discouraged(e.g. No Click-bait).

Descriptions go hand in hand with titles. Make sure your description provides information via links on the items covered in the video. The above snapshot of the Vsauce video “Which Way is Down?” provides a nice title and so much content on how to learn more on what is covered in the video. I would suggest checking it out.

You can also add tags which are relevant to your video, but tags don’t really effect the view rate of your video.

Cards and End Screens

Cards are notifications that can appear throughout the video. They are small rectangular boxes appearing within the video which should link to relevant content, like merchandise or related videos.

End Screens provide clickable links at the end of your YouTube video. They can be used to entice a viewer to:

• View another video or playlist
• Encourage viewer to subscribe
• Cross-promote another youtube channel
• Link to approved websites

Promoting on Social Media

Once your video is complete and has been published, we need to get it out in the world. What better way than to share it!

I usually share through the following mediums:

• Twitter: Twitter is an amazing platform for connecting with others with similar interests, send out a tweet with relevant text so that it’s searchable.
• LinkedIn: Lot’s of your coworkers might be on LinkedIn, it would be nice for them to share the articles with all their colleagues.
• Slack: Be sure to share it within your organization’s slack channels, that way others can begin to promote your content.
• Reddit: With the videos being technical, and not too markety, they can be shared on different subreddits.
• Medium: If you are writing a relevant blog, it would be good to include a link to your video.

I hope this guide inspires you to get out there and create some great content. I have so much fun creating these videos and you should too. 😎

I was very fortunate to qualify for the GitLab CEO Shadow program after there was a last minute slot opening. In this program I followed Sid through his daily work routine (and some of his personal ventures).

I got to see the inner workings of GitLab, as well as attend meetings with a variety of different Silicon Valley CEOs. Just having a program like this shows how transparent GitLab is.

In this post, I’m going to go over 4 things I’ve learned after completing the program.

How to make and communicate key decisions

As a CEO shadow I was able to attend board meetings. These board meeting really showed me how key decisions are made using data and how they are communicated out to the employees.

Having data is one of the most important factors in decision making. You need to know certain criteria the be able to answer some of these questions:

• Is this implementation feasible?
• How long will it take to implement?
• Will we need more people to work on the implementation?
• Will employees be happy and motivated implementing this?
• What benefit is derived from this implementation and when will we see the benefit?

These questions can be answered by looking at past data, customer information and having input from a diverse team of individuals with different experiences.

Once a decision is made it needs to be communicated to the employees in a proper manner. Quickly after making a decision was made an AMA was set up with the appropriate parties. This allows employees to provide questions and receive support for their needs by management.

The importance of writing things down

As CEO Shadow I attended meetings from all parts of the company. I learned about support, marketing, sales, development, and so much more. With so many decisions being made for such diverse aspects of the company, it is so important to write things down when they are said.

Memory can get foggy, so it is important that you can go back and see what key decisions were made, and the dialogue which backed these decisions. Notes are taken in detail for every meeting and action items come from those notes.

To add to the importance of writing, at GitLab we keep a public handbook, which provides detailed information on how we run the company. Similar to a Legal System, we continue to iterate on and append sections to our handbook. Not only does this enable collaboration between all employees, but it allows us to grow as a company and allow everyone to have a voice via Merge Request.

The importance of collaboration

GitLab is all about community and teamwork, it’s so nice to have 2 shadows at once, following a learn from one and teach one. It really make the program that more fun.

I learned from [David Fisher](https://about.gitlab.com/company/team/#dfishis1).

and taught [Dan Parry](https://about.gitlab.com/company/team/#dparry)

We became buddies and would help each other out on taking notes and updating the handbook, and other tasks provided by the CEO. This really builds a feeling of rapport between co-workers.

How to manage time efficiently

I was amazed at how efficiently a CEO’s day is planned. I attended GitLab meetings as well as personal meetings for the CEO’s other ventures.

I noticed that every meeting was started and ended in the proper amount of time. Not only that, but there was no time wasted in meetings and the items that needed to be discussed were discussed. This makes the use of our time very efficient and allows us to make things for other things in life.

We could all take a page from the [Communication] section from the GitLab Handbook (https://about.gitlab.com/handbook/communication/)

I also noted that important personal events were included also in the CEO calendar. This inspired me, and I went ahead a started adding important things like working out, calling friends, and more to my calendar, so I can not only manage my work time, but also my life time.

In Conclusion, it was an amazing experience and I feel very inspired. I’m grateful to work for such a transparent company.

Thanks for reading, and I hope you enjoyed this post!