Blog - Jakob Zanker

How To Inject Environment Variables Into a React Application On Runtime

In this blog post I want to show you how you can inject environment variables into a React application.

Separating config from code is a good practice for designing applications. For example you need to add config to your front end application, when you have it deployed in different environments, e.g. a staging and a production environment.

Baking the configuration into the code or the Docker image both violates the principle of separating config from code.

The solution is to pass as environment variables, e.g. the API URL of the back end, to React when the Docker container starts up.

But since a React application is just bundled static HTML/JavaScript/CSS, your front end cannot directly pick up the environment variables available on the server side!

This blog post shows you how you nonetheless can do it:

Automated screenshot comparison tests with headless Chrome, Puppeteer and Pixelmatch, in Bitbucket pipeline

In this blog post I want to show how to set up automated screenshot comparison tests with a headless Chrome browser, using Puppeteer and Pixelmatch, in a Bitbucket pipeline. A simple react application will be used to test.

Screenshots are taken using Puppeteer and a headless Chrome browser. The screenshots are compared with baseline images using Pixelmatch and a simple helper function. If the actual screenshot matches the baseline image, the test succeeds, otherwise it fails. The react application under test uses a rest backend (which is mocked in the pipeline).

In the end of the blog post, you’ll find a link to a Github repository that contains a working example of the setup.

How to create a single Fluentd log stream for each Kubernetes service in AWS CloudWatch

In this blog post I show you how to create a single fluentd log stream per kubernetes micro service in AWS CloudWatch.

I was setting up logging for a kubernetes cluster (Amazon EKS) with fluentd. After I followed the tutorial provided by AWS, I found that the log streams showing in AWS CloudWatch are per container per pod. That means that you cannot see all the logs of a service in one place, because you have your logs from one service distributed over multiple log streams.

Being new to working with fluentd, it took me quite some time to change the configuration, so that you have all the logs of one service unified in a log stream, which, I think, makes much more sense as a default config. This blog post shows, how to do it.