Ingo Pfennigstorf

Sometimes the most sophisticated deployment strategies and
infrastructure models can unfortunatly not be shifted into the real
life, so one has to go back a few decades and use tools from that time
and mix them with current ones.

In a former [post](/jekyll-docker.html) I described a cool solution for
building a static HTML website and putting it into a Docker image. This
method could not be used for serving the blog (don't ask about details
...), so I was forced to use a shared Webhosting that runs a webserver
and multiple websites at once.

So far, so good, nothing wrong with that, but the crux of matter is,
that the only deployment (a.k.a copying the build artifacts) solution
provided by the hoster is SFTP. I cannot really remember, if I ever used
SFTP, because most times back in the days one used FTP or SCP. SCP was
not available, because SSH is not installed on the webserver, and we
don't need to talk about using FTP nowadays.

As the code of this blog resides in a Gitlab repository and we do have
some experience with Gitlab CI, AND we wanted the sites to be deployed
automatically on change the task was to take the built HTML files and
copy them via SFTP to the webserver.

I don't want to put usernames and passwords and sensitive information in
a code repository, so first of all, some variables for that CI tasks
need to be defined, such as `SFTP_USERNAME`{.language-plaintext
.highlighter-rouge}, `SFTP_PASSWORD`{.language-plaintext
.highlighter-rouge}, `WEBSERVER`{.language-plaintext .highlighter-rouge}
and `PORT`{.language-plaintext .highlighter-rouge}.

After googling around for a while, I found a scriptable SFTP-Client that
completely fits my needs for the task: [lftp](https://lftp.yar.ru/).

As seen below, the deployment uses a [Ruby Docker
image](https://hub.docker.com/_/ruby/), installs all dependencies in the
`before_script`{.language-plaintext .highlighter-rouge} section, builds
the static HTML website, does some SSH weakening and finally copies the
build artifacts to the final destination.

::: {.language-yaml .highlighter-rouge}
::: {.highlight}
``` highlight
image: ruby:2.3 variables: JEKYLL_ENV: production before_script: - bundle install oldschool: stage: deploy script: - bundle exec jekyll build -d public - apt-get update -yqq && apt-get install -yqq lftp - 'which ssh-agent || ( apt-get install openssh-client -y )' - mkdir -p ~/.ssh - eval $(ssh-agent -s) - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config' - lftp -c "mirror -R public/ sftp://$SFTP_USERNAME:$SFTP_PASSWORD@$WEBSERVER:$PORT/www/lab" artifacts: paths: - public 
```
:::
:::


Sometimes the most sophisticated deployment strategies and infrastructure models can unfortunatly not be shifted into the real life, so one has to go back a few decades and use tools from that time and mix them with current ones. In a former post I described a cool solution for building a static HTML website and putting it into a Docker image.

(S)FTP and Gitlab CI

Well, this might be a catchy title. But what we are going to do, is to
put the Jekyll artifacts into a Docker image and get a completely
self-contained website.

## Jekyll, what? Artifacts?

Ok, let's start from the very beginning. [Jekyll](https://jekyllrb.com/)
is a static website generator. This blog is run by Jekyll. That means,
we do only have to edit markdown files and a ruby program generates
everything around that and transforms the posts into a website. Usually
this is a task done by CMS, such as [TYPO3](https://typo3.org) or
[Wordpress](https://wordpress.org), but we don't need a complete PHP and
MySQL-based solution for that.

The artifacts are generated by Jekyll upon deployment or locally and
consist of a static HTML website with all assets, such as images,
stylesheets and so on, included.

The main advantage is (as stated above), we only need a dumb webserver
to run this, no JVM, no PHP interpreter, no Ruby, no ...

## Building It

So, our task here is, to generate the HTML files and put everything into
a Docker Container, that includes an Apache Webserver. And that is
basically everything we have to do in our Dockerfile:

::: {.language-Dockerfile .highlighter-rouge}
::: {.highlight}
``` highlight
FROM ruby:2.3 as build ENV JEKYLL_ENV: production WORKDIR /usr/src/app COPY . /usr/src/app RUN bundle install && \  bundle exec jekyll build -d public FROM httpd:2.4-alpine COPY --from=build /usr/src/app/public/ /usr/local/apache2/htdocs/ 
```
:::
:::

This Dockerfile is quite interesting, even as it is really, really
short. It starts building the Jekyll stuff with the
`ruby:2.3`{.language-plaintext .highlighter-rouge} image, that is later
referenced as `build`{.language-plaintext .highlighter-rouge}. Jekyll
generates its arfifacts and puts them into the directory
`public`{.language-plaintext .highlighter-rouge}, as we defined it in
the command `bundle exec jekyll build -d public`{.language-plaintext
.highlighter-rouge}.

After the artifacts are built, we refer to another image. the 'official'
Apache Webserver image `httpd:2.4-alpine`{.language-plaintext
.highlighter-rouge}. I am using the `alpine`{.language-plaintext
.highlighter-rouge} version here, because it results in much smaller
Docker images. In the lat line, we copy the `public`{.language-plaintext
.highlighter-rouge} directory from the formerly generated ruby-based
image into the new httpd-image in the desired root-directory for the
Apache Webserver.

And that's it!

When we are building that with
`docker build -t lab .`{.language-plaintext .highlighter-rouge} a
self-contained Blog with a bundled Webserver is created. The image, that
is only 32MB small, may be run with
`docker run -it --rm --name lablab -p 9878:80 lab`{.language-plaintext
.highlighter-rouge} and when opening <http://localhost:9878> in the
browser, the blog is served!

### Y U no nginx?

You might ask. One does not simply use nginx, but just to add the same
for [nginx](https://nginx.org):

::: {.language-Dockerfile .highlighter-rouge}
::: {.highlight}
``` highlight
FROM ruby:2.3 as build ENV JEKYLL_ENV: production WORKDIR /usr/src/app COPY . /usr/src/app RUN bundle install && \  bundle exec jekyll build -d public FROM nginx:1.13-alpine COPY --from=build /usr/src/app/public/ /usr/share/nginx/html/ 
```
:::
:::

And the answer to the question in the headline is: I have no experience
using nginx and trying to use the `alpine`{.language-plaintext
.highlighter-rouge} version of the `nginx`{.language-plaintext
.highlighter-rouge} image resultet in the error, that the desired
platform is not supported
([`no matching manifest for linux/amd64 in the manifest list entries`{.language-plaintext
.highlighter-rouge}](https://github.com/docker-library/official-images/issues/3835)),
that means, at the time of the writing the desired image has not been
available, because the Docker Hub images are eventually consistent, due
to different build server environments and capabilities.


Well, this might be a catchy title. But what we are going to do, is to put the Jekyll artifacts into a Docker image and get a completely self-contained website. Jekyll, what? Artifacts? Ok, let’s start from the very beginning. Jekyll is a static website generator. This blog is run by Jekyll. That means, we do only have to edit markdown files and a ruby program generates everything around that and transforms the posts into a website.

Serving a Jekyll Blog with Docker

Carsten Thiel

## Technology fails -- at least sometimes.

This is particularly true for a modern distributed research
infrastructure, such as [DARIAH-DE](https://de.dariah.eu/).

For the operation of this infrastructure, we have implemented a
monitoring solution with [Icinga](https://www.icinga.com/). This enables
us to be informed about problems and react quickly. In an ideal state,
our world looks like this:
![monitoring](assets/images/dariah-status-monitoring.webp)

As well as this works, the problems we face are manifold:

1.  Users don't know if someone is already working on a red icon here.
2.  This map shows only the current state, but sometimes maintenances
    must be announced in advance.
3.  The monitoring itself is not entirely independent from the
    infrastructure.

Usually, our engineers are quick in identifying problems and fixing
them. But if users start querying them about the status of the issue
they are working on, it won't get fixed quicker.

So we decided to build an independent and manually curated status page.

## GitHub status page

The first approach, was to have a static HTML file on GitHub pages with
[current information](https://dariah-de.github.io/status/). The
advantages of this approach are:

- The status page is entirely independent from our infrastructure and
  reasonably reliant.
- Security-wise, static pages are probably the best you can do.
- Authentication and authorisation are handled entirely outside our
  infrastructure. But since it's GitHub, we feel reasonably safe to
  assume that everyone will have their credentials at hand even in a
  stressful event such as a datacenter outage.

This page was well-received by users and is now checked regularly by our
power users in case of problems, instead of picking up the phone
immediately.

![status](assets/images/dariah-status-OK.webp)

However, as the infrastructure grows, the number of dependencies
increases and sometimes it is hard to list all services affected by a
single outage.

## Now powered by Jekyll

We decided to include the service dependencies directly into the GitHub
page by utilising [Jekyll's
Collections](https://jekyllrb.com/docs/collections/).

The services, middlewares and infrastructure components are now modelled
in `yaml`{.language-plaintext .highlighter-rouge} datasets.

::: {.language-yaml .highlighter-rouge}
::: {.highlight}
``` highlight
title: 'Example Service' dependencies: - '/infrastructure/storagesystem' - '/servers/mymachine' 
```
:::
:::

So in case of emergencies, we can add the actually broken parts to a
Jekyll data file.

::: {.language-yaml .highlighter-rouge}
::: {.highlight}
``` highlight
- title: 'The storage is full!' description: "Don't worry, we ordered a few new hard drives." date_start: '2018-02-12 11:01' affected: - '/infrastructure/storagesystem' 
```
:::
:::

Then, using recursive liquid templates, we get a list of all of the
affected services. In the above example, it would list at least *Example
Service* but any other services that (indirectly) depends on
*storagesystem*.

![status](assets/images/dariah-status-exampleerror.webp)

Of course, the same approach is possible for announcements of upcoming
maintenances. For more details on the implementation, see the [official
documentation](https://dariah-de.github.io/status/documentation.html) or
the [source code](https://github.com/DARIAH-DE/status).

## Status quo

The implementation is relatively new and not yet complete as of writing
this article. ![status](assets/images/dariah-status-graph.webp) The
graph shows the currently known dependencies. Following a
`git push`{.language-plaintext .highlighter-rouge}, GitHub will generate
the new page, as long as all dependencies can be resolved. In parallel,
[Travis-CI](https://travis-ci.org/) will rebuild the dependency graph
and compare it to the committed version using
[NetworkX](https://networkx.github.io/).

Rebuilding the graph and populating the
[history](https://dariah-de.github.io/status/history.html) is still
manual, as this reduces complexity and future-proofs the tool for
changes in the infrastructure that would break dependency resolution for
historical data.

This solution was also the topic of a [FOSDEM'18 lightning
talk](https://fosdem.org/2018/schedule/event/static_infrastructure_status/)
by the author:

Your browser seems not to support video embedding!


Technology fails – at least sometimes. This is particularly true for a modern distributed research infrastructure, such as DARIAH-DE.  For the operation of this infrastructure, we have implemented a monitoring solution with Icinga. This enables us to be informed about problems and react quickly.

Messaggi di Rogue Scholar

(S)FTP and Gitlab CI

Serving a Jekyll Blog with Docker

Static Infrastructure Status with Jekyll and GitHub Pages