DEV Community: André König

How to Avoid Network Policies Interfering with Workload Identity on the Google Kubernetes Engine

André König — Tue, 16 Aug 2022 12:00:00 +0000

Today we stumbled upon an interesting case which I want to share as it might help you in your debugging journey.

Let's assume you have the following infrastructure setup:

Kubernetes Cluster on the Google Kubernetes Engine
Workload Identity enabled.
egress Network Policies in use.

Problem

You might think everything is fine, but your service which is communicating with Google APIs (like Google Cloud Storage Client Libraries, etc.) complains with something like:

Could not load the default credentials.
Browse to https://cloud.google.com/docs/authentication/getting-started for more information.

The first reaction is: How can this be the case when I configured Workload Identity as recommended? When looking behind the curtain it is likely that the culprit here is not Workload Identity at all.

Cause

In our case, the root cause was a restrictive network policy which blocked the egress traffic to the GKE metadata server.

Solution

The solution depends slightly on the Kubernetes version you're operating.

1.21.0-gke.1000 and later

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: your-network-policy
  namespace: default
spec:
  egress:
  - ports:
    - port: 988
      protocol: TCP
    to:
    - ipBlock:
        cidr: 169.254.169.252/32
  policyTypes:
  - Egress

Prior versions

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: your-network-policy
  namespace: default
spec:
  egress:
  - ports:
    - port: 988
      protocol: TCP
    to:
    - ipBlock:
        cidr: 127.0.0.1/32
  policyTypes:
  - Egress

Deactivate the Scrollbar. The sidebar is visible!

André König — Tue, 12 Jan 2021 15:11:00 +0000

Imagine the following – pretty common – scenario:

You have some kind of UI where you open up a sidebar by clicking on a Hamburger icon. The sidebar is positioned above the actual UI components. So far, nothing special 🎉 The case hits you when you have a lot of components within the actual view so that the browser does what it is really good in, scrolling.

So the question is, how to temporarily deactivate scrolling when the sidebar has been opened?

A 🍔, please.

Before diving into the solution space, let's set the foundation and define the actual Hamburger component. This component is responsible for handling the sidebar visibility.


import { useState, FunctionComponent } from "react";

export const Hamburger: FunctionComponent = () => {
  const [ isSidebarVisible, setIsSidebarVisible ] = useState(false);

  const onClick = () =>
    setIsSidebarVisible(!isMenuOpen);

  return (
    <a href="#" onClick={onClick}>🍔</a>
  );
};

This is only the component for the visibility state handling of the sidebar – the Hamburger icon. The actual sidebar gets displayed via React Portals. I have omitted the usage of Portals here for reasons of simplicity.

Now, where we have the actual state in place, we can utilize that information for toggling whether the viewport scrolling should be active or not.

Meet the `<Scrollbar />` component

One of my favorite aspects about styled-components is the paradigm of using encapsulated components for creating visual representations. But you don't need to stop there, you can utilize it for controlling global behavior as well. The following snippet shows you how to define a component which controls the global scrollbar by using styled-component's own createGlobalStyle mechanism:

type Props = {
  deactivated?: boolean
}

export const Scrollbar = createGlobalStyle<Props>`
  body {
    overflow: ${props => props.deactivated ? "hidden" : "auto"};
  }
`;

With this component in place, we can now deactivate the global scrollbar via <Scrollbar deactivated /> and activate it by rendering just <Scrollbar />.

Using the `<Scrollbar />`

Back to our <Hamburger /> component. Integrating the scrollbar component is quite easy:

import { useState, FunctionComponent } from "react";

const Hamburger: FunctionComponent = () => {
  const [ isSidebarVisible, setIsSidebarVisible ] = useState(false);

  const onClick = () =>
    setIsSidebarVisible(!isSidebarVisible);

  return (
    <>
      <Scrollbar deactivated={isSidebarVisible} />

      <a href="#" onClick={onClick}>🍔</a>
    </>
  );
};

Now whenever the sidebar has been opened, this state indicates that the scrollbar should be deactivated and vice versa 🥳

Conclusion

Although the solution demonstrates quite a nice declarative solution, please take it with a grain of salt. Encapsulating global behavior should be used sparsely. When using such an encapsulation in different places of your code base, this certain areas gets hard to maintain over time as you might loose track of them. Even with this word of caution, there are cases, like the described scenario, where it might be quite handy to wrap global behavior in a component and use it conditionally.

Demo

A full example can be found here: conditional-scrollbar.

First Impressions of Knative Eventing

André König — Wed, 10 Jul 2019 10:26:23 +0000

You might have heard of Knative – the serverless application development platform on top of Kubernetes. A lot of buzzwords, I know, but in essence it provides multiple APIs for deploying your applications without thinking (too much) about Kubernetes machinery.

At the moment, Knative can be differentiated into three components:

Knative Serving - Deploying HTTP-based applications – think of AWS Lambda or Google Cloud Functions
Knative Build - Helps you to avoid touching containers at all. You provide code and the rest will happen automagically.
Knative Eventing - Helps you to build event-driven applications 💥

You might know that I'm a huge fan of event-driven architectures. This is why we will explore Knative Eventing in this post a little bit.

What do I need?

Due to the nature of Knative as a serverless platform on top of Kubernetes, you need – 🎉 – a Kubernetes cluster with an installed Service Mesh, like Istio. No worries, if you don't know what this Istio-thingy is all about. Please ignore it for the moment and just treat it as a requirement.

For everyone who is not a proud owner of a Kubernetes cluster yet, I recommend creating one on the Google Cloud Platform (GCP). In general the following steps are required:

Create a cluster on GCP with the Istio addon
Install Knative

To keep things DRY and not duplicating content, you can find a good description in the official docs of Knative: Install on Google Kubernetes Engine.

⚠️ Don't be quenched by the node autoscaling configuration (1 - 10 nodes). For this demo, you can just remove --enable-autoscaling --min-nodes=1 --max-nodes=10 and replace it with --num-nodes 1. This results in a single node cluster which is sufficient for our little exploration here.

Our goal

So what is our goal here? I thought of a simple scenario which demonstrates all the essential key pieces without to much ceremony involved. The result is the following simple use case:

Establishing an emitter which sends a JSON-formatted event every minute and having an application which spins up automatically and just displays the respective event.

Let the events flow ...

The described use case above can be translated into the following architecture which demonstrates how the flow of events can be achieved with Knative Eventing:

Although that might look complex, the introduced indirection with the Broker and Trigger makes a lot of sense in the end. Let us analyze it piece by piece.

Broker

The Broker acts as a central eventing gateway. It receives events from sources and delegates it to the respective subscribers who are interested in the event.

In our scenario, we will create broker in the default namespace by executing:

kubectl label namespace default knative-eventing-injection=enabled

You can verify the creation of the broker via:

$ kubectl get broker
NAME      READY   REASON   HOSTNAME                                   AGE
default   True             default-broker.default.svc.cluster.local   22s

Event Source

Acts as an origin of events. Imagine a microservice kind of architecture. In such a scenario you would have multiple of such event sources. Each of them will emit domain specific events.

There are several possibilities to establish an actual event source. Beside coding own sources, Knative Eventing ships with a bunch of predefined of those. To name a few:

GitHub: Repository / Organization events, like: PR created, commits pushed, etc.
Apache Kafka: Stream Kafka messages to Knative
Kubernetes: Brings Kubernetes cluster events to Knative

You can find a complete list of existing sources in the Knative docs.

Another interesting predefined component is the Cron Job source. It allows to emit messages in a timely manner. This is exactly the one, we want to use in our demo here:

# filename: source.yaml
apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
  name: event-emitter
spec:
  schedule: "* * * * *"
  data: '{"message": "Hello world!"}'
  sink:
    apiVersion: eventing.knative.dev/v1alpha1
    kind: Broker
    name: default

This is everything you need to define a Cron Job source. You can apply it via:

kubectl apply -f source.yaml

Afterwards, the event-emitter will ...

... send the event defined in data every minute
... send this message to the default broker

Service

The service is your actual application. The one which is responsible for receiving the respective event and performing some business logic. In our example, we just use an existing container image which takes a received event and prints it on stdout.

The definition looks like:

# service.yaml
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: dumper
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display

The service will be alive after executing kubectl apply -f service.yaml and the logs can be digested via:

kubectl logs -f  -l serving.knative.dev/service=dumper -c user-container --since=10m

Although we have applied Broker, Source and the Service you might be wondering why you can't see any output yet. This leads us to our last missing puzzle piece, the Trigger

Trigger

A Trigger is an interesting beast to be honest. It acts as an indirection layer in which you can define which events should be send to which service. It basically binds a respective event type to a specific service. Nice and declarative, eh?

# trigger.yaml

apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
  name: trigger
spec:
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1alpha1
      kind: Service
      name: dumper

So after a kubectl apply -f trigger.yaml, we basically created a component which triggers the service every time a new event arrives. You should see an output in the logs of the service from now on.

Conclusion

In some of my previous customer projects we created such an eventing infrastructure ourselves. You may already have had the experience to build such a thingy. It is quite a lot of work, right? Establishing the broker infrastructure (via RabbitMQ, Apache Kafka, etc.) and defining all the event routing manually just to name two aspects of the overall work. Knative Eventing ships with the correct primitives IMHO. It enables you to perform all the work you had to do manually in the past in a nice, declarative way.

My assumption is that Knative in general is facing a bright future. A lot of engineers just avoided touching Kubernetes due to its high learning curve. You might consider the ecosystem again. Knative is here to let you focus on shipping code without a lot of infrastructural overhead.

What is your impression of Knative and Knative Eventing in general?

Handling errors in GraphQL

André König — Wed, 14 Feb 2018 09:26:09 +0000

There has been some discussions recently about how to handle errors in GraphQL resolvers. I mentioned apollo-errors because I had very good experiences with it. In this article, I want to take the chance and describe my approach of handling errors in a GraphQL API.

Anatomy of an error

Before diving deep into how to establish a proper error handling, I would like to differentiate a little bit what kind of errors we are talking about here. Basically, as in all user-facing systems, there are two possible error types:

Controlled errors: An exception which indicates that the user did something wrong (e.g. Wrong login credentials, etc.)
Uncontrolled errors: The counterpart. An exception that indicates that something really bad happened (e.g. storage system not available, etc.)

The ones we are most interested in are the controlled errors. These are the ones which you as the software engineer define and throw when the particular case has happened. Uncontrolled errors, as the name states, are the ones which can happen all the time. Even if they are not controllable, you will learn how to handle them gracefully as well.

The common approach

When reading about GraphQL, you will often see the following example:

if (!areCredentialsValid) {
    throw new Error("Authentication required");
}

This is a simple approach and might be sufficient in most cases. The downside here is that a respective client has a hard time figuring what kind of an error this actually is. A err.message === "Authentication required" in the client is not cool at all.

It would be great to have a kind of error type, right? This is where apollo-errors comes to play. Let's go!

A more robust approach

Let's consider the following scenario: We have a login mutation and we want to throw an error when the user entered wrong credentials. A possible type could be WrongCredentialsError. The first step to do is creating the actual error type:

// path: resolvers/mutation/login/errors/WrongCredentialsError.ts

import { createError } from "apollo-errors";

const WrongCredentialsError = createError("WrongCredentialsError", {
    message: "The provided credentials are invalid."
});

export { WrongCredentialsError }

Now where we have our error type, we can throw it from our login mutation resolver:

// path: resolvers/mutation/login/index.ts

import { WrongCredentialsError } from "./errors/WrongCredentialsError";

interface LoginInput {
  username: string;
  password: string;
}

const login = await (parent, args: LoginInput, context: Context, info) {
    const user = await context.db.query.user({where: {username: args.username}});

    const areCredentialsValid = checkCredentials(user, args.password);

    if (!areCredentialsValid) {
        throw new WrongCredentialsError();
    }
};

So when this mutation gets executed and the user entered wrong credentials the GraphQL API would respond with:

{
  "data": {},
  "errors": [
    {
      "message":"The provided credentials are invalid.",
      "name":"WrongCredentialsError",
      "time_thrown":"2018-02-14T00:40:50.954Z",
    }
  ]
}

Pretty, isn't it? So, in theory the GraphQL API would respond with this. There is one missing puzzle piece. Due to the different error structure, we have to tell the GraphQL API endpoint that those errors should be formatted differently.

But no worries, installing the formatter is an one-time shot and easily done. The following describes how to hook the formatter up on a graphql-yoga based application.

import { GraphQLServer, Options } from "graphql-yoga";
import { formatError } from "apollo-errors";

const options: Options = {
  formatError
};

const server = new GraphQLServer({ typeDefs, resolvers })
server.start(options, () => console.log('GraphQL API is running on localhost:4000'))

That's it! You're able to throw named controlled errors now.

Handling uncontrolled errors gracefully

As promised above, I mentioned to give you an approach to handle uncontrolled errors gracefully as well. You may have read from the code snippets, that I use Prisma for interacting with my database. Let us assume that I've messed something up (e.g. sent a stuffy query to my database, etc.). In those cases, where something really bad happened, we want to inform the client that a FatalError occurred. How can we achieve this?

One approach would be to put each Prisma interaction in a try / catch and throw the FatalError there. That would work, but is pretty cumbersome because you have to handle that in all your resolvers.

The other approach could be to wrap all our resolvers into a wrapper that executes the actual resolver and checks if that resolver didn't throw an uncontrolled error. Let us call this wrapper helmet. It could look like:

// path: resolvers/helmet.ts

import { FatalError } from "./errors/FatalError";

const helmet = (resolver) => async (...args) => {
  try {
    //
    // Try to execute the actual resolver and return
    // the result immediately.
    //
    return await resolver(...args);
  } catch (err) {
    //
    // Due to the fact that we are using Prisma, we can assume
    // that each error from this layer has a `path` attribute.
    //
    // Note: The `FatalError` has been created before by
    // using `apollo-errors` `createError` function.
    //
    if (err.path) {
      throw new FatalError({ data: { reason: err.message } });
    } else {
      throw err;
    }
  }
};

export { helmet };

In order to actually handle the uncontrolled errors gracefully, you have to wrap your resolvers into that helmet function. Here for example, we use the login mutation described above:

// path: resolvers/mutation/index.ts

import { helmet } from "../helmet";

import { login } from "./login";

const Mutation = {
  login: helmet(login)
  // ...
};

export { Mutation };

Conclusion

Even when just throwing an Error object right away might be sane in some scenarios, I would suggest considering an approach like the one described in this post for larger applications. Remember, one of GraphQL's strengths is its expressiveness. Why shouldn't you treat your errors also like that?

I hope you enjoyed the post and I'm happy to hear your thoughts :)

Deploying a Prisma cluster to Kubernetes

André König — Tue, 13 Feb 2018 06:52:10 +0000

This post was originally written as a tutorial for the official Prisma documentation.

Motivation

In this tutorial, you will learn how to deploy a Prisma server on Kubernetes.

Prisma is thin layer around your database which exposes a GraphQL API for interacting with your data. It helps you to build your business logic on top by defining an own GraphQL API which communicates with this particular Prisma service.

Kubernetes is a container orchestrator that helps with deploying and scaling of your containerized applications.

The setup in this tutorial assumes that you have a running Kubernetes cluster in place. There are several providers out there that gives you the possibility to establish and maintain a production grade cluster. This tutorial aims to be provider agnostic, because Kubernetes is actually the abstraction layer. The only part which differs slightly is the mechanism for creating persistent volumes. For demonstration purposes, we use the Kubernetes Engine on the Google Cloud Platform in this tutorial.

I compiled all the files for you in this repository so that you don't have to copy and paste out of this blog post :)

Prerequisites

If you haven't done that before, you need to fulfill the following prerequisites before you can deploy a Prisma cluster on Kubernetes. You need ...

... a running Kubernetes cluster (e.g. on the Google Cloud Platform)
... a local version of kubectl which is configured to communicate with your running Kubernetes cluster

You can go ahead now and create a new directory on your local machine – call it kubernetes-demo. This will be the reference directory for our journey.

Creating a separate namespace

As you may know, Kubernetes comes with a primitive called namespace. This allows you to group your applications logically. Before applying the actual namespace on the cluster, we have to write the definition file for it. Inside our project directory, create a file called namespace.yml with the following content:

apiVersion: v1
kind: Namespace
metadata:
  name: prisma

This definition will lead to a new namespace, called prisma. Now, with the help of kubectl, you can apply the namespace by executing:

kubectl apply -f namespace.yml

Afterwards, you can perform a kubectl get namespaces in order to check if the actual namespace has been created. You should see the following on a fresh Kubernetes cluster:

❯ kubectl get namespaces
NAME            STATUS    AGE
default         Active    1d
kube-public     Active    1d
kube-system     Active    1d
prisma          Active    2s

MySQL

Now that we have a valid namespace in which we can rage, it is time to deploy MySQL. Kubernetes separates between stateless and stateful deployments. A database is by nature a stateful deployment and needs a disk to actually store the data. As described in the introduction above, every cloud provider comes with a different mechanism of creating disks. In the case of the Google Cloud Platform, you can create a disk by following the following steps:

Open the Google Cloud Console
Go to the Disk section and select Create

Please fill out the form with the following information:

Name: Should be db-persistence
Zone: The zone in which the Nodes of your Kubernetes cluster are deployed, e.g. europe-west-1c
Disk type: For a production scenario SSD persistent disk
Source type: None (blank disk)
Size (GB): Select a size that fits your requirements
Encryption: Automatic (recommended)

Select Create for actually creating the disk.

Note: To keep things simple, we created the disk above manually. You can automate that process by provisioning a disk via Terraform as well, but this is out of the scope of this tutorial.

Deploying the MySQL Pod

Now where we have our disk for the database, it is time to create the actual deployment definition of our MySQL instance. A short reminder: Kubernetes comes with the primitives of Pods and ReplicationControllers.

A Pod is like a "virtual machine" in which a containerized application runs. It gets an own internal IP address and (if configured) disks attached to it. The ReplicationController is responsible for scheduling your Pod on cluster nodes and ensuring that they are running and scaled as configured.

In older releases of Kubernetes it was necessary to configure those separately. In recent versions, there is a new definition resource, called Deployment. In such a configuration you define what kind of container image you want to use, how much replicas should be run and, in our case, which disk should be mounted.

The deployment definition of our MySQL database looks like:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: database
  namespace: prisma
  labels:
    stage: production
    name: database
    app: mysql
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        stage: production
        name: database
        app: mysql
    spec:
      containers:
        - name: mysql
          image: 'mysql:5.7'
          args:
            - --ignore-db-dir=lost+found
            - --max-connections=1000
            - --sql-mode=ALLOW_INVALID_DATES,ANSI_QUOTES,ERROR_FOR_DIVISION_BY_ZERO,HIGH_NOT_PRECEDENCE,IGNORE_SPACE,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_BACKSLASH_ESCAPES,NO_DIR_IN_CREATE,NO_ENGINE_SUBSTITUTION,NO_FIELD_OPTIONS,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_UNSIGNED_SUBTRACTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY,PIPES_AS_CONCAT,REAL_AS_FLOAT,STRICT_ALL_TABLES,STRICT_TRANS_TABLES,ANSI,DB2,MAXDB,MSSQL,MYSQL323,MYSQL40,ORACLE,POSTGRESQL,TRADITIONAL
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: "graphcool"
            - name: MYSQL_DATABASE
              value: "graphcool"
          ports:
            - name: mysql-3306
              containerPort: 3306
          volumeMounts:
            - name: db-persistence
              readOnly: false
              mountPath: /var/lib/mysql
      volumes:
        - name: db-persistence
          gcePersistentDisk:
            readOnly: false
            fsType: ext4
            pdName: db-persistence

When applied, this definition schedules one Pod (replicas: 1), with a running container based on the image mysql:5.7, configures the environment (sets the password of the root user to graphcool) and mounts the disk db-persistence to the path /var/lib/mysql.

To actually apply that definition, execute:

kubectl apply -f database/deployment.yml

You can check if the actual Pod has been scheduled by executing:

kubectl get pods --namespace prisma

NAME                        READY     STATUS    RESTARTS   AGE
database-3199294884-93hw4   1/1       Running   0          1m

It runs!

Deploying the MySQL Service

Before diving into this section, here's a short recap.

Our MySQL database pod is now running and available within the cluster internally. Remember, Kubernetes assigns a local IP address to the Pod so that another application could access the database.

Now, imagine a scenario in which your database crashes. The cluster management system will take care of that situation and schedules the Pod again. In this case, Kubernetes will assign a different IP address which results in crashes of your applications that are communicating with the database.

To avoid such a situation, the cluster manager provides an internal DNS resolution mechanism. You have to use a different primitive, called Service, to benefit from this. A service is an internal load balancer that is reachable via the service name. Its task is to forward the traffic to your Pod(s) and make it reachable across the cluster by its name.

A service definition for our MySQL database would look like:

apiVersion: v1
kind: Service
metadata:
  name: database
  namespace: prisma
spec:
  ports:
  - port: 3306
    targetPort: 3306
    protocol: TCP
  selector:
    stage: production
    name: database
    app: mysql

The definition would create an internal load balancer with the name database. The service is then reachable by this name within the prisma namespace. A little explanation about the spec section:

ports: Here you map the service port to the actual container port. In this case the mapping is 3306 to 3306.
selector: Kind of a query. The load balancer identifies Pods by selecting the ones with the specified labels.

After creating this file, you can apply it with:

kubectl apply -f database/service.yml

To verify that the service is up, execute:

kubectl get services --namespace prisma

NAME       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
database   ClusterIP   10.3.241.165   <none>        3306/TCP   1m

Prisma

Okay, fair enough, the database is deployed. Next up: Deploying the actual Prisma server which is responsible for serving as an endpoint for the Prisma CLI.

This application communicates with the already deployed database service and uses it as the storage backend. Therefore, the Prisma server is a stateless application because it doesn't need any additional disk storage.

Deploying the Prisma Pod

Deploying the actual Prisma server to run in a Pod is pretty straightforward. First of all you have to define the deployment definition:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: prisma
  namespace: prisma
  labels:
    stage: production
    name: prisma
    app: prisma
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        stage: production
        name: prisma
        app: prisma
    spec:
      containers:
        - name: prisma
          image: 'prismagraphql/prisma:1.1'
          ports:
            - name: prisma-4466
              containerPort: 4466
          env:
            - name: PORT
              value: "4466"
            - name: SQL_CLIENT_HOST_CLIENT1
              value: "database"
            - name: SQL_CLIENT_HOST_READONLY_CLIENT1
              value: "database"
            - name: SQL_CLIENT_HOST
              value: "database"
            - name: SQL_CLIENT_PORT
              value: "3306"
            - name: SQL_CLIENT_USER
              value: "root"
            - name: SQL_CLIENT_PASSWORD
              value: "graphcool"
            - name: SQL_CLIENT_CONNECTION_LIMIT
              value: "10"
            - name: SQL_INTERNAL_HOST
              value: "database"
            - name: SQL_INTERNAL_PORT
              value: "3306"
            - name: SQL_INTERNAL_USER
              value: "root"
            - name: SQL_INTERNAL_PASSWORD
              value: "graphcool"
            - name: SQL_INTERNAL_DATABASE
              value: "graphcool"
            - name: SQL_INTERNAL_CONNECTION_LIMIT
              value: "10"
            - name: CLUSTER_ADDRESS
              value: "http://prisma:4466"
            - name: BUGSNAG_API_KEY
              value: ""
            - name: ENABLE_METRICS
              value: "0"
            - name: JAVA_OPTS
              value: "-Xmx1G"
            - name: SCHEMA_MANAGER_SECRET
              value: "graphcool"
            - name: SCHEMA_MANAGER_ENDPOINT
              value: "http://prisma:4466/cluster/schema"
            - name: CLUSTER_PUBLIC_KEY
              value: "GENERATE VIA https://api.cloud.prisma.sh/"

This configuration looks similar to the deployment configuration of the MySQL database. We tell Kubernetes that it should schedule one replica of the server and define the environment variables accordingly. As you can see, we use the name database for each SQL_*_HOST* variable. This works because of the fact that this Pod will run in the same namespace as the database service – the Kubernetes DNS server makes that possible.

Before applying that definition, we have to generate a public/private-keypair so that the CLI is able to communicate with this Prisma server. Head over to https://api.cloud.prisma.sh/ and execute the following query:

{
  generateKeypair {
    public
    private
  }
}

Make sure to store those values in a safe place! Now, copy the public key and paste it into the value of the CLUSTER_PUBLIC_KEY environment variable in prisma/deployment.yml.

Afterwards, we are ready to apply that deployment definition:

kubectl apply -f prisma/deployment.yml

As in the previous sections: In order to check that the Prisma server has been scheduled on the Kubernetes cluster, execute:

kubectl get pods --namespace prisma

NAME                        READY     STATUS    RESTARTS   AGE
database-3199294884-93hw4   1/1       Running   0          5m
prisma-1733176504-zlphg     1/1       Running   0          1m

Yay! The Prisma server is running! Off to our next and last step:

Deploying the Prisma Service

Okay, cool, the database Pod is running and has an internal load balancer in front of it, the Prisma server Pod is also running, but is missing the load balancer a.k.a. Service. Let's fix that:

apiVersion: v1
kind: Service
metadata:
  name: prisma
  namespace: prisma
spec:
  ports:
  - port: 4466
    targetPort: 4466
    protocol: TCP
  selector:
    stage: production
    name: prisma
    app: prisma

Apply it via:

kubectl apply -f prisma/service.yml

Okay, done! The Prisma server is now reachable within the Kubernetes cluster via its name prisma.

That's all. Prisma is running on Kubernetes!

The last step is to configure your local Prisma CLI so that you can communicate with the instance on the Kubernetes Cluster.

The upcoming last step is also necessary if you want to integrate prisma deploy into your CI/CD process.

Configuration of the Prisma CLI

The Prisma server is running on the Kubernetes cluster and has an internal load balancer. This is a sane security default, because you won't expose the Prisma server to the public directly. Instead, you would develop a GraphQL API and deploy it to the Kubernetes cluster as well.

You may ask: "Okay, but how do I execute prisma deploy in order to populate my data model when I'm not able to communicate with the Prisma server directly?. That is indeed a very good question!kubectl` comes with a mechanism that allows forwarding a local port to an application that lives on the Kubernetes cluster.

So every time you want to communicate with your Prisma server on the Kubernetes cluster, you have to perform the following steps:

kubectl get pods --namespace prisma to identify the pod name
kubectl port-forward --namespace prisma <the-pod-name> 4467:4466 – This will forward from 127.0.0.1:4467 -> kubernetes-cluster:4466

The Prisma server is now reachable via http://localhost:4467. With this in place, we can configure the CLI:

`
prisma cluster add

? Please provide the cluster endpoint http://localhost:4467
? Please provide the cluster secret
? Please provide a name for your cluster kubernetes
`

Okay, you made it! Congratulations, you have successfully deployed a Prisma server to a production Kubernetes cluster environment.

Docker: Restricting in- and outbound network traffic

André König — Tue, 10 Oct 2017 14:58:36 +0000

Imagine a scenario in which you might have a stinky module deep in your dependency graph. A dependency that wants to do something evil – a malware. "But I'm isolating everything in a Docker container at runtime!", you might say. Indeed, that helps when the evil module tries to mess up with your filesystem or other host related aspects. But what if the module wants to phone home?”

I thought about that problem today and want to share my approach with you. Before I headed straight into tinkering, I created the following acceptance criteria:

The container should accept in- and outbound traffic from and to a known network
The container should block in- and outbound traffic from and to all other networks
The application within the container should run as a non-privileged user

"A privileged user is necessary for restricting network traffic." was my first thought which conflicts with the third acceptance criteria. Meh!

After implementing some test probes, I settled with the following solution:

Provisioning of a base image which ships with a non-privileged user and an ENTRYPOINT script
The ENTRYPOINT script gets executed when the container starts, defines the iptables rules and starts the given application as the configured non-privileged user afterwards.

Let's have a look at the actual solution. The Dockerfile:

FROM node:8-alpine

LABEL maintainer="AndrÃ© KÃ¶nig <andre.koenig@gmail.com>"

RUN apk add --update curl iptables sudo && \
    addgroup -S app && adduser -S -g app app

COPY entrypoint.sh /entrypoint.sh

ENTRYPOINT ["/entrypoint.sh", "--"]

As you can see, pretty straight forward: Using a base image – in this case the Node.js 8 Alpine image, adding a new user group and creating a new user. The second part copies the entrypoint.sh script into the container and defines it as an ENTRYPOINT. Nothing special here. So let's define the actual entrypoint.sh:

#!/usr/bin/env sh

#
# iptables configuration
#
# The following allows in- and outbound traffic
# within a certain `CIDR` (default: `192.168.0.0/24`),
# but blocks all other network traffic.
#
ACCEPT_CIDR=${ALLOWED_CIDR:-192.168.0.0/24}

iptables -A INPUT -s $ACCEPT_CIDR -j ACCEPT
iptables -A INPUT -j DROP
iptables -A OUTPUT -d $ACCEPT_CIDR -j ACCEPT
iptables -A OUTPUT -j DROP

#
# After configuring `iptables` as root, execute
# the passed command as the non-privileged `app` user.
#
sudo -u app sh -c "$@"

Usage examples

After bulding the image via docker build -t node-sandbox ., let's test drive this new sandboxed environment.

For example, in order to test if there is really no outbound traffic, try:

docker run --privileged -it --rm node-sandbox "curl https://google.com"

curl should give up after some time and you will see an curl: (6) Could not resolve host: google.com error.

On the other hand, communicating with a system in your local network should work. So if you live in the 192.168.0.0/24 network and you have something running on 192.168.0.1 (maybe your wifi router), you should see a response when executing:

docker run --privileged -it --rm node-sandbox "curl http://192.168.0.1"

The attentive reader might have noticed that the entrypoint.sh checks if the environment variable ALLOWED_CIDR is set and takes the CIDR notated network instead of the fallback:

docker run --privileged -it --rm -e "ALLOWED_CIDR=10.0.0.0/8" node-sandbox "curl http://10.0.0.1"

Conclusion

One of my clients had to tranform highly sensible user data within a Node.js-based application over and over again. Because of high security standards within that organization, they anticipated an isolated network environment in which no possible evil dependency could ever reach out and send sensible information to an external system. Despite the fact that the application doesn't run within a container orchestrator where you have fine-grained control over the network stack, but on a user machine, this seems to be a solution that works quite well. If you face a similar situation, this approach might assist you and I'm happy to read your views.

react-apollo: An approach to handle errors globally

André König — Mon, 02 Oct 2017 16:54:01 +0000

Well, I had quite a journey today and I would like to share it with you. I'm – like most of you – a huge fan of GraphQL and the Apollo Stack. Those two technologies + React: declarative rendering + declarative data fetching â¤ï¸ - Is there anything that would make a dev happier? I guess there are many things, but anyways. One thing that bothered me a lot today was handling errors globally. ðŸ˜¤

Imagine the following scenario: An unexpected error occurred. Something really bad. The UI can't and shouldn't recover from that state. You would love to display a completely different UI which informs the user about that case. The Apollo client, or the react-apollo binding to be precisely, is pretty good when it comes to handling occurred errors on a local level. Something in the vein of: You have a component that "binds" to a GraphQL query and whenever an error occurred you will display something different within that component:


import { compose } from "recompose";
import { graphql, gql } from "react-apollo";

import { ErrorHandler } from "./components";

const NewsList = compose(
  graphql(gql`
    query news {
      id
      name
    }
  `)
)(({ data }) =>
  <div>
    {data.loading ? (
      <span>Loading ...</span>
    ) : data.errors ? (
      <ErrorHandler errors={data.errors} />
    ) : (
      <ul>
        data.news.map(entry => <li key={entry.id}>{entry.name}</li>)
      </ul>
    )}
  </div>
);

There is nothing wrong with that approach, except that it doesn't fulfil our aspired scenario in which we want to display an UI the user can't "escape" from. How can we achieve that then?

Afterwares to the rescue!

The Apollo Client comes with a mechanism called Afterware. An Afterware gives you the possibility to hook you right into the network layer of the Apollo client. It is a function that gets executed whenever a response comes from the server and gets processed by the client. An example:

// graphql/index.js

import ApolloClient, { createNetworkInterface } from "react-apollo";

const createClient = ({ endpointUri: uri }) => {
  const networkInterface = createNetworkInterface({ uri });

  networkInterface.useAfter([{
    applyAfterware({ response }, next) {
      // Do something with the response ...
      next();
    }
  }]);

  return new ApolloClient({ networkInterface });
};

export { createClient };

Before diving into how to handle the actual error, I would like to complete the example by defining how to create the actual client and use it in your app. The following would be your entry component that bootstraps your application:

// index.js
import { render } from "react-dom";
import { ApolloProvider } from "react-apollo";

import { App } from "./App";
import { createClient } from "./graphql";

const $app = document.getElementById("app");

const client = createClient({
  endpointUri: "https://api.graph.cool/..."
});

render(
  <ApolloProvider client={client}>
    <App />
  </ApolloProvider>
, $app);

So that is this. Creating the client and passing it to the ApolloProvider. Now what? I promised you that we wan't to display a scene which doesn't allow the user to interact with the app. After some tinkering I came to the conclusion that there is a simple solution for that. So here is the dopey idea: Let's pass an additional function to the createClient function, called onError which takes an error object and performs a complete new render on the $app DOM node. That would allow us to unmount the corrupt UI and render a different component for displaying the respective error case to the user ðŸ¿

First of all: Let's adjust the bootstrapping of the app by defining the onError function and passing it to the createClient call:

// index.js
import { render } from "react-dom";
import { ApolloProvider } from "react-apollo";

import { App } from "./App";
import { createClient } from "./graphql";

const $app = document.getElementById("app");

const client = createClient({
  endpointUri: "https://api.graph.cool/...",
  onError: error => render(
    <MyErrorHandler error={error} />
  , $app)
});

render(
  <ApolloProvider client={client}>
    <App />
  </ApolloProvider>
, $app);

Afterwards, we have to adjust our Afterware so that it calls that passed onError function whenever the server responds with errors:

// graphql/index.js

import ApolloClient, { createNetworkInterface } from "react-apollo";

const createClient = ({ endpointUri: uri, onError }) => {
  const networkInterface = createNetworkInterface({ uri });

  networkInterface.useAfter([{
    applyAfterware({ response }, next) {
      if (response.status === 500) {
        return onError(new Error(`A fatal error occurred`));
      }

      next();
    }
  }]);

  return new ApolloClient({ networkInterface });
};

export { createClient };

Wohoo! That's it! From now on, your application would display your <MyErrorHandler /> whenever an error occurred. Mission completed!

Would be great when we could use error boundaries which has been introduced in React 16, but that is not possible due the not "throwing nature" of the Apollo client (which is a good thing when you want to have fine-grained error handling capabilities).

That is it from me for now. Hope you enjoyed the ride and maybe this approach is also useful for you :)

Happy coding!

What is the best mechanical keyboard out there?

André König — Thu, 07 Sep 2017 14:19:38 +0000

First of all: I have to admit that I'm more or less a newbie when it comes to mechanical keyboards.

There are a lot of engineers who seems to favour this kind of keyboard over the others. A couple of weeks ago I tried one by myself and was kind of flashed. It feels so much better than the common Apple keyboards I'm usually hacking on. Therefore, I did some research and found the CODE keyboard which seems to be a nice fit.

Before buying one, I thought it might be a good idea to ask all of you: What keyboard do you feel most comfortable with?

DEV Community: André König

How to Avoid Network Policies Interfering with Workload Identity on the Google Kubernetes Engine

Problem

Cause

Solution

Deactivate the Scrollbar. The sidebar is visible!

A 🍔, please.

Meet the <Scrollbar /> component

Using the <Scrollbar />

Conclusion

Demo

First Impressions of Knative Eventing

What do I need?

Our goal

Let the events flow ...

Broker

Event Source

Service

Trigger

Conclusion

Handling errors in GraphQL

Anatomy of an error

The common approach

A more robust approach

Handling uncontrolled errors gracefully

Conclusion

Deploying a Prisma cluster to Kubernetes

Motivation

Prerequisites

Creating a separate namespace

MySQL

Deploying the MySQL Pod

Deploying the MySQL Service

Prisma

Deploying the Prisma Pod

Deploying the Prisma Service

Configuration of the Prisma CLI

Docker: Restricting in- and outbound network traffic

Usage examples

Conclusion

react-apollo: An approach to handle errors globally

Afterwares to the rescue!

What is the best mechanical keyboard out there?

Meet the `<Scrollbar />` component

Using the `<Scrollbar />`