When JFrog released Artifactory 7 they changed the way you can install Artifactory quiet a bit by introducing some sort of installation script for the Docker Compose setup. The documentation always was a bit brief and therefore I never understud why I need to download a TAR, then run a script on a server to get single instance of Artifactory up and running with Docker Compose.

Since then I always felt a bit lost, and honestly I did not want to spend time on investigating how the «new installation process» works and why I became more difficult. Starting in 2023 JFrog released this installation video that explains the simplest setup using Artifactory 7 with Postgres.

But again that video does helped me a lot, since I still need to run a script and that script produces two Docker Compose YAML files. One for Artifactory and another one for Postgres. That's not what I'm looking for. Furthermore, most or almost all examples related to Docker Compose refer to version 6 of Artifactory.

So this time I started digging. The intention of this blog post is to give experienced developers and/or ops a starting point. A Docker Compose YAML file that works, and simply can be developed further.

Let's start with the .env file that hold global configuration values. First of all we want to use Artifactory 7.55.9 which is the latest version as of this writing. With ROOT_DATA_DIR we set the root path for the Docker volumes (Postgres- & Artifactory data) to persist application data. Last but not least we define that port 8080 is the port Artifactory accepts external calls.

ARTIFACTORY_VERSION = 7.55.9
ROOT_DATA_DIR = /opt/jfrog/artifactory/volumes
JF_ROUTER_ENTRYPOINTS_EXTERNALPORT = 8080

Then let's take a look at our docker-compose.yml. As mentioned before it contains a Postgres database «postgres» and Artifactory «artifactory».

version: '3.9'
services:
    postgres:
        image: postgres:13.9-alpine
        container_name: postgresql
        environment:
            - POSTGRES_DB=artifactory
            - POSTGRES_USER=artifactory
            - POSTGRES_PASSWORD=gravis
        ports:
            - "127.0.0.1:5432:5432"
        volumes:
            - ${ROOT_DATA_DIR}/postgres/var/data/postgres/data:/var/lib/postgresql/data
            - /etc/localtime:/etc/localtime:ro
        restart: always
        deploy:
            resources:
                limits:
                    cpus: "1.0"
                    memory: 500M
        logging:
            driver: json-file
            options:
                max-size: "50m"
                max-file: "10"
        ulimits:
            nproc: 65535
            nofile:
                soft: 32000
                hard: 40000

    artifactory:
        image: releases-docker.jfrog.io/jfrog/artifactory-oss:${ARTIFACTORY_VERSION}
        container_name: artifactory
        environment:
            - JF_ROUTER_ENTRYPOINTS_EXTERNALPORT=${JF_ROUTER_ENTRYPOINTS_EXTERNALPORT}
        ports:
            - "127.0.0.1:${JF_ROUTER_ENTRYPOINTS_EXTERNALPORT}:${JF_ROUTER_ENTRYPOINTS_EXTERNALPORT}" # for router communication
#            - 8081:8081 # for artifactory communication
        volumes:
            - ${ROOT_DATA_DIR}/artifactory/var:/var/opt/jfrog/artifactory
            - /etc/localtime:/etc/localtime:ro
        restart: always
        logging:
            driver: json-file
            options:
                max-size: "50m"
                max-file: "10"
        deploy:
            resources:
                limits:
                    cpus: "2.0"
                    memory: 4G
        ulimits:
            nproc: 65535
            nofile:
                soft: 32000
                hard: 40000

Additonally you need to configure Arifactory by providing a system.yaml configuration file.

shared:
    node:
        ip: 127.0.0.1
        id: artifactory-one
        name: artifactory-one
    database:
        type: postgresql
        driver: org.postgresql.Driver
        password: gravis
        username: artifactory
        url: jdbc:postgresql://postgres:5432/artifactory
router:
    entrypoints:
        externalPort: 8080

So this is how your directory should look like

.
├── .env
├── docker-compose.yml
└── volumes
    └── artifactory
        └── var
            └── etc
                └── system.yaml

When running docker compose up -d and waiting while, you finally can login to your fresh Artifactory 7 installation on http://localhost:8080/ by using the default user admin with password password.

I hope this helps you setting up Artifactory. As mention this is the very minimum, feel free to extend it to your needs.

As a bonus please find the resource consumption of a bored Artifactory accompanied by a Postgres database running on Apple Silicon M1.

Java Money (JSR-354) provides an excellent API (and SPI) to deal with money in Java. The following example shows how easily it can be used with Java Streams to sum up MonetaryAmounts.

Given the following list with two monetary amounts of CHF 12.50 and CHF 99.35

we can easily calculate the grand total (sum up the monetary amounts) by using Java Streams. Note that Money is backed by a BigDecimal so precision is respected. For the sake of readability the code examples are working with double values.

The result is a monetary amount sum with CHF 111.85. Neat, isn't it?

But why MonetaryFunctions?

The example above uses MonetaryFunctions::sum to sum up the monetary amounts. Of course you could simply use MonetaryAmount::add as shown in the listing below.

By using MonetaryFunctions::sum you make sure, that only monetary amounts of the same currency are summed up. If you try to sum up CHF 5.50 and $ 12.33 using MonetaryAmount::add, you then get MonetaryException.

In this post I'm going to show you how you can install Docker Compose version 2 on a Linux system and register a systemctl service.

Install Docker Compose

Docker Compose releases are available at the following Git Hub repository https://github.com/docker/compose/releases. This means we easily can download the binary for e.g. a 64 bit Linux operating system. In the example below I use curl to perform the download and store it at /usr/libexec/docker/cli-plugins/docker-compose.

sudo curl -SL https://github.com/docker/compose/releases/download/v2.12.2/docker-compose-linux-x86_64 -o /usr/libexec/docker/cli-plugins/docker-compose

Now we need to make sure that the binary is executable.

sudo chmod 755 /usr/libexec/docker/cli-plugins/docker-compose

Install a Systemctl Service

Now I want to run my docker composition as a service to make sure the composition starts when the operating system starts. Therefore I create a new file myservice.service at /etc/systemd/system.

[Unit]
Description=My service with docker compose
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=true
WorkingDirectory=<path to your Docker composition
ExecStart=/usr/libexec/docker/cli-plugins/docker-compose up -d --remove-orphans
ExecStop=/usr/libexec/docker/cli-plugins/docker-compose down

[Install]
WantedBy=multi-user.target

Finally we register the new service by executing sudo systemctl enable myservice.service. Et voilà, the service is registered and can be started using sudo systemctl start myservice.service.

Have you ever wondered how Micronaut Security internally works? Well, I did and here is want I have found. Hope you enjoy it.

I'm a visual person, meaning I love pictures or any other visuals to understand a certain topic. Recently I had to enable Basic Authentication within a Micronaut 3.6.x application. The nice thing is, that I simply had to apply the following two dependencies to my Gradle build.

depdendencies {
	annotationProcessor("io.micronaut.security:micronaut-security-annotations")
	implementation("io.micronaut.security:micronaut-security")
    // ... other dependencies omitted
}

By adding these two dependencies, Micronaut Security is part of your application. As a next step I needed to turn on the security feature and secure the API paths.

micronaut:
  application:
    name: artinaut
  security:
    enabled: true # turn on Micronaut Security
    basic-auth:
      enabled: true # enable basic authentication (default is: true)
    intercept-url-map: # Secure the API
      - pattern: /api/v1/**
        access:
          - ADMIN
      - pattern: /repos/**
        access:
          - isAnonymous()
          - isAuthenticated()

HTTP Request with path /api/v1/** automatically require an authenticated user having the role ADMIN. And HTTP requests to /repos/** are available to the public. So how do I tell Micronaut Security about my users and their roles? The answer is that I need to provide an AuthenticationProvider. So here is what I did.

1. Pick the username from the AuthenticationRequest.
2. Try to read the user from the database using the username.
3. Comparing the hashed passwords and either return a successful or a failed AuthenticationResponse.

@Singleton
@RequiredArgsConstructor
@Slf4j
public class MyAuthenticationProvider implements AuthenticationProvider {

  private final UserService userService;
  private final PasswordEncoder passwordEncoder;

  @Override
  public Publisher<AuthenticationResponse> authenticate(
      HttpRequest<?> httpRequest, AuthenticationRequest<?, ?> authenticationRequest) {
    return Flux.create(
        emitter -> {
          String identity = (String) authenticationRequest.getIdentity();
          UserDto user = userService.findUser(identity).orElse(null);

          if (user != null) {

            if (passwordEncoder.matches(
                (String) authenticationRequest.getSecret(), user.password())) {

              final Set<String> roles =
                  user.groups().stream()
                      .map(GroupDto::roles)
                      .flatMap(Collection::stream)
                      .map(RoleDto::name)
                      .collect(Collectors.toSet());
              emitter.next(AuthenticationResponse.success(identity, roles));
            } else {
              log.debug(
                  "Password does not match for user «{}» (user id «{}»)", identity, user.id());
              emitter.next(AuthenticationResponse.failure());
            }

          } else {
            emitter.next(AuthenticationResponse.failure());
          }
          emitter.complete();
        },
        FluxSink.OverflowStrategy.ERROR);
  }
}

Easy as pie, thank you Micronaut. It works! But wait, I want to dig in deeper. What else is involved? Since Micronaut does not rely on reflection their source code is very easy to read and debug. I ended up with the following, simplified sequence diagram. It explains what other participants are involved in the authentication process, even before my AuthenticationProvider gets invoked.

I hope you liked it. Thank you for reading.

Keycloak 17+ is not based on Wildfly anymore but uses Quarkus. This makes it a first-class citizen for running it as a Docker container. Quarkus reduces the startup time of Keycloak massively and reduces its memory footprint. Previously a Keycloak Docker container based on Wildfly consumed around ~800 MB RAM and took roughly 30 seconds to be up and running. Keycloak 17+ (Codename Keycloak.X) changes this by consuming ~300MB RAM and starts almost instantly.

Therefore I was super keen on giving the new Keycloak setup a try and run it on my local machine as a Docker container. This article is about my failures and the eventual success.

My main goal is to run Keycloak, as mentioned as a Docker container connected to a MariaDB database. As mentioned in the Keycloak documentation it is highly recommended to build your own optimised Keycloak Docker image.

For the best start up of your Keycloak container, build an image by running the build step during the container build. This step will save time in every subsequent start phase of the container image.

Easy, let's give it a try

So I started with a MariaDB and a optimised Keycloak Docker image, that listens on http port 8080. In my first attempt I build the optimised Keycloak image using the following Dockerfile.

FROM quay.io/keycloak/keycloak:18.0.0 as builder

ENV KC_DB=mariadb
RUN /opt/keycloak/bin/kc.sh build

FROM quay.io/keycloak/keycloak:18.0.0
COPY --from=builder /opt/keycloak/ /opt/keycloak/
WORKDIR /opt/keycloak
ENTRYPOINT ["/opt/keycloak/bin/kc.sh", "start"]

In the first phase I use the base image quay.io/keycloak/keycloak:18.0.0 to build my optimised Keycloak setup, declaring that I want to use MariaDB. In the second stage I pack the optimised output of the builder stage and put it into my Docker image.

docker build --no-cache . -t ghcr.io/saw303/zscsupporter-be/keycloak-18.0.0:0.0.1

Then I setup a Docker composition declaring a reverse proxy (Caddy), my Keycloak image and the MariaDB.

version: "3.9"
services:
  proxy:
    image: caddy:2.5.1-alpine
    ports:
      - "${PROXY_IP}:80:80"
      - "${PROXY_IP}:443:443"
    volumes:
      - ${BASE_PATH:-.}/docker-volume/caddy/Caddyfile:/etc/caddy/Caddyfile:Z
      - ${BASE_PATH:-.}/docker-volume/caddy/caddy_data:/data:Z
      - ${BASE_PATH:-.}/docker-volume/caddy/caddy_config:/config:Z
  
  keycloak:
    image: ghcr.io/saw303/zscsupporter-be/keycloak-18.0.0:0.0.1
    ports:
      - "127.0.0.1:9001:8080"
      - "127.0.0.1:9443:8443"
    environment:
      KC_HOSTNAME: localhost
      KC_HOSTNAME_PORT: 80
      KC_HOSTNAME_STRICT_BACKCHANNEL: true
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: admin
      KC_DB_URL: jdbc:mariadb://keycloakdb:3306/keycloak
      KC_DB_USERNAME: keycloak
      KC_DB_PASSWORD: secret
      KC_LOG_LEVEL: info
      KC_PROXY: edge

  keycloakdb:
    image: mariadb:10.7.3-focal
    environment:
      MYSQL_ROOT_PASSWORD: root_secret
      MYSQL_DATABASE: keycloak
      MYSQL_USER: keycloak
      MYSQL_PASSWORD: secret
      TZ: "Europe/Zurich"
    tmpfs:
      - /var/lib/mysql:rw
    ports:
      - "127.0.0.1:3307:3306"

My initial idea was to access Keycloak and its Admin Console using http (insecure), since I was running it on my local machine. The Caddyfile for Caddy Server 2.0 looks like this.

{
  admin off
}

localhost:80

reverse_proxy /* keycloak:8080

log

It simply passed all the request to the Keycloak container running on port 8080. But as you might have guessed. That did not work out very well. Clicking on the Admin Console link ended up in a blank browser page.

FFS, ...after some other failed attempts

I took my a while to understand that the Admin Console is requiring secure access by design. I did not find any way around it but finally found a why to make my reverse proxy creating self-signed certificates. So here is a working setup.

First of all, you need to configure Caddy to listen on e.g. port 443 and create a self-signed certificate by declaring tls internal.

{
  admin off
}

localhost:443 {
        reverse_proxy keycloak:8080
        tls internal
}

log

Then you need to build Keycloak a bit differently.

FROM quay.io/keycloak/keycloak:18.0.0 as builder

ENV KC_FEATURES=token-exchange
ENV KC_DB=mariadb
RUN /opt/keycloak/bin/kc.sh build

FROM quay.io/keycloak/keycloak:18.0.0
COPY --from=builder /opt/keycloak/ /opt/keycloak/
WORKDIR /opt/keycloak
ENTRYPOINT ["/opt/keycloak/bin/kc.sh", "start"]

And finally you got to adjust the Docker composition.

version: "3.9"
services:
  proxy:
    image: caddy:2.5.1-alpine
    ports:
      - "${PROXY_IP}:80:80"
      - "${PROXY_IP}:443:443"
    volumes:
      - ${BASE_PATH:-.}/docker-volume/caddy/Caddyfile:/etc/caddy/Caddyfile:Z
      - ${BASE_PATH:-.}/docker-volume/caddy/caddy_data:/data:Z
      - ${BASE_PATH:-.}/docker-volume/caddy/caddy_config:/config:Z

  keycloak:
    image: ghcr.io/saw303/zscsupporter-be/keycloak-18.0.0:0.0.1
    ports:
      - "127.0.0.1:9443:8443"
    restart: unless-stopped
    environment:
      KC_DB_URL: jdbc:mariadb://keycloakdb:3306/keycloak
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: admin
      KC_HOSTNAME: localhost
      KC_HOSTNAME_STRICT: false
      KC_HTTP_ENABLED: true
      KC_DB_USERNAME: keycloak
      KC_DB_PASSWORD: secret
      KC_PROXY: edge

  keycloakdb:
    image: mariadb:10.7.3-focal
    environment:
      MYSQL_ROOT_PASSWORD: root_secret
      MYSQL_DATABASE: keycloak
      MYSQL_USER: keycloak
      MYSQL_PASSWORD: secret
      TZ: "Europe/Zurich"
    tmpfs:
      - /var/lib/mysql:rw
    ports:
      - "127.0.0.1:3307:3306"

And this is how it worked for me. Have fun with your local Keycloak container on https://localhost.  Hope this helps.

You maybe know these situations. You just left your home and commute to work by the public transport. While traveling you connect your MacBook with your personal hot spot or maybe with a hotspot that is provided by the train or bus company. Anyway, you start to work and you're maybe listening to music with a pair of headphones on. Suddenly you realize you forgot to mute your MacBook and passengers around you might be entertained by audio feedbacks of your terminal or other applications.

Would it be nice to automatically mute the Mac when I connect to foreign Wifi hotspots? And turn the volume back up when I return home? Well this can be easily achieve with Hammerspoon. Hammerspoon allows you to implement such an use case using Lua. The script below welcomes you with a message and sets the volume to 80% when you connect to your Wifi at home. When you connect to another Wifi, it mutes the MacBook.

wifiWatcher = nil
homeSSID = "my-wifi"
lastSSID = hs.wifi.currentNetwork()

function ssidChangedCallback()
    newSSID = hs.wifi.currentNetwork()

    if newSSID == homeSSID and lastSSID ~= homeSSID then
        -- We just joined our home WiFi network
        hs.audiodevice.defaultOutputDevice():setVolume(80)
        hs.alert.show("Welcome home")
    elseif newSSID ~= homeSSID and lastSSID == homeSSID then
        -- We just departed our home WiFi network
        hs.audiodevice.defaultOutputDevice():setVolume(0)
        hs.alert.show("You are now connected to " .. newSSID)
    end

    lastSSID = newSSID
end

wifiWatcher = hs.wifi.watcher.new(ssidChangedCallback)
wifiWatcher:start()

I hope you found the short article helpful and enjoyed it.

Recently I wanted to map configuration list within the application.yml into an immutable configuration object of a Micronaut application. The YAML configuration is fairly simple. It defines a list of instances containing fields such as name, version, endpoint and read-timeout.

a:
  b:
    instances:
      - name: T1
        endpoint: "http://t1"
        version: "1.5.3.24305,2021-08-09 18:01"
        read-timeout: 20
      - name: T2
        endpoint: "http://t1"
        version: "2.0.0.16555,2022-01-03 16:48"
        read-timeout: 20

Now I created an immutable Java configuration and wanted Micronaut to bind the YAML onto my configuration.

@ConfigurationProperties("a.b")
public interface MyConfig {

  List<Instance> getInstances();

  interface Instance {
    String getName();
    URL getEndpoint();
    String getVersion();
    int getReadTimeout();
  }
}

Easy, so far. As good developers we are used to write tests and this is what I did to verify whether everything is working as expected.

@MicronautTest
class MyConfigSpec extends Specification {
  @Inject
  MyConfig config

  void "Make sure the config has instances"() {

    expect:
    config.instances.isEmpty() == false
  }
}

Guess what. The test failed 🥺. getInstances() always returns an empty list no matter what I do. After debugging a while I realized that Jackson ObjectMapper is trying to create an instance of Instance but obviously can't since there is no implementation present. But migrating the interface Instance into a concrete class did work either. At that point I was not sure what's really going on here so I posted my problem to Stack Overflow. Within less than 4 hours my problem was solved.

The solution is simple. We need to help Micronaut and introduce a dedicated TypeConverter that allows Micronaut to convert a Map into an Instance. Here is an example of Szymon Stepniak.

@Singleton
class MapToInstanceConverter implements TypeConverter<Map, Instance> {

    @Override
    public Optional<Instance> convert(Map object, Class<Instance> targetType, ConversionContext context) {
        return Optional.of(new Instance() {
            @Override
            public String getName() {
                return object.getOrDefault("name", "").toString();
            }

            @Override
            public URL getEndpoint() {
                try {
                    return new URI(object.getOrDefault("endpoint", "").toString()).toURL();
                } catch (MalformedURLException | URISyntaxException e) {
                    throw new RuntimeException(e);
                }
            }

            @Override
            public String getVersion() {
                return object.getOrDefault("version", "").toString();
            }

            @Override
            public int getReadTimeout() {
                return Integer.parseInt(object.getOrDefault("read-timeout", 0).toString());
            }
        });
    }
}

This converter made my test go green. Configuration binding done! Hope this helps.

Have you ever been in the situation that everything runs smoothly in your IDE or on your machine and then the build breaks on your command line or CI?

Well, in this case you might want to attach your IDE Debugger and inspect whats going on. This brief article will show you how to do it.

On your local machine you simply tell Gradle to run in debug mode and without the Gradle Daemon. Run your tests using the check task.

gradle --no-daemon -Dorg.gradle.debug=true check

After that you can attach your IDEs Debugger onto port 5005 and see whats actually happening with your test.

This is a repost of my blog post in 2016. Recently I was asked to do a small intro into the Geb. These are the results of a small workshop I gave at Adcubum.

So what is it?

Geb is a really nice and handy browser automation tool on top Selenium Webdriver. It provides you the full power of Selenium Webdriver. But it adds some nice features such as:

• a much more readable DSL
• Page objects to structure your test code and make it reusable.
• Integration with the Spock Framework

And how does it look like?

Page objects help you to encapsulate the content of a specific page and reuse it in several test classes. In this example GoogleFrontPage provides an easy to use identifier for example the Google search input field. It also provides you an easy way to click on the Google search button.

class GoogleFrontPage extends geb.Page {

    static url = '/'

    static at = {
        title == 'Google'
    }

    static content = {
        searchInputField { $("input", name: "q") }

        searchButton { $("button", name: "btnG") }

        searchResultsContainer { $('#sbfrm_l') }

        searchResults { $('h3.r') }

        firstResult { searchResults[0] }
    }
}

This enables you as a developer to write much more readable test code by writing commands like

to GoogleFrontPage 

which tells Geb to browse to http://www.google.com. You can then tell Geb to enter some text into search input field of the Google Search Engine by writing

 searchInputField.value = 'Geb Framework'

and then start the Google search by clicking on the

button.searchButton.click()

Putting all of this together

The listing below shows you the entire Geb test case implemented as a Spock specification. Looks neat, right?

@spock.lang.Stepwise
class GoogleSpec extends geb.spock.GebReportingSpec {

  void "Visit Google.com"() {

    when:
    to GoogleFrontPage

    then:
    title == 'Google'
  }

  void "Make sure the query field is initially empty"() {

    expect: 'The search field is initially empty'
    searchInputField.text() == ''
  }

  void "Enter a query"() {

    when: 'Enter "Geb Framework" into the search field'
    searchInputField.value = 'Geb Framework'

    and: 'Click the search button'
    searchButton.click()

    and: 'wait until the search result element is visible'
    waitFor { searchResultsContainer.displayed }

    then:
    title == 'Geb Framework - Google Search'

    and:
    firstResult.text() == 'Geb - Very Groovy Browser Automation'
  }
}

Where can I get that stuff?

I wrote a small starter tutorial that is hosted at https://github.com/saw303/geb-starter/. Feel free to clone it and run those tests yourself.

I wanna see more!

As initially mentioned the workshop was held in german. Therefore the recordings only are available in German language.

Recently I had to split a large application into several smaller applications. The source code of that application was in single Git repository and had well-encapsulated modules within its own sub directories such as module-a.

large-application
├── module-a
├── module-b
└── module-c

Since the modules where already encapsulated the main goal was to extract the modules into new dedicated Git repositories. And here is how I achieved it.

Mission: Extraction

First let's start by going into the Git repository of the large application.

cd ~/large-application

For now we concentrate on extracting module module-a and we do this by telling Git to create a subtree of your directory and store that subtree in a new branch called feature/split-module-a.

git subtree split -P module-a -b feature/split-module-a

After this we create a new empty Git repository for module-a.

mkdir ~/new-repo
cd ~/new-repo
git init

Alright, we are about done here. All we need to do is to move the extracted branch from the source Git repository to the target Git repository.

git pull ~/large-application feature/split-module-a

This is it. Now your new repo contains only the module-a related commits in the new Git repository.

This post is inspired by the following answer at Stackoverflow.

There are situations where you want to copy a file from your machine to a running Docker container or vice versa. Especially in cases when the Docker container does not use a volume that is bound to your local file system.  For these situations you can use one of the approaches described below.

Use Pipes

Pipes are a fantastic way passing data from one process to another. The following example uses cat to read the file content of the missing_data.sql and hands it over to the running Docker container.

cat missing_data.sql | \ 
docker exec -i <your container name> \
sh -c 'cat > /missing_data.sql'

Once this process has been completed you will find the file inside the container at /missing_data.sql.

Use the Docker Binary

Nevertheless copying can be achieved by using pipes, I recommend to use the copy utility of the Docker binary. It is much easier to ready and simpler to write.

docker cp missing_data.sql <container-id>:/missing_data.sql

I hope this helped you exchanging files with Docker containers