Apache Karaf on Azure cloud

In previous post, I showed the “new” Docker tooling (http://blog.nanthrax.net/?p=839).

In this blog post, we will use a Karaf Docker image on Azure cloud.

Creating our Karaf Docker image

For this post, we will start from a Karaf instance where we install the Karaf REST example.

So, on a running Karaf instance, we change etc/org.apache.karaf.features.cfg to add REST example as featuresBoot:

...featuresRepositories = \     mvn:org.apache.karaf.features/enterprise/4.2.1/xml/features, \    mvn:org.apache.karaf.features/spring/4.2.1/xml/features, \    mvn:org.apache.karaf.features/standard/4.2.1/xml/features, \    mvn:org.apache.karaf.features/framework/4.2.1/xml/features, \    mvn:org.apache.karaf.examples/karaf-rest-example-features/4.2.1/xml...featuresBoot = \     instance/4.2.1, \    package/4.2.1, \    log/4.2.1, \    ssh/4.2.1, \    framework/4.2.1, \    system/4.2.1, \    eventadmin/4.2.1, \    feature/4.2.1, \    shell/4.2.1, \    management/4.2.1, \    service/4.2.1, \    jaas/4.2.1, \    deployer/4.2.1, \    diagnostic/4.2.1, \    wrap/2.5.4, \    bundle/4.2.1, \    config/4.2.1, \    kar/4.2.1, \    karaf-rest-example-provider...

We package our Karaf folder as a tar.gz archive, let’s say kloud.tar.gz:

tar zcvf kloud.tar.gz apache-karaf-4.2.1

Now, as explained in the previous Karaf Docker blog post, we create the Karaf Docker image using assemblies/docker/build.sh provided in Karaf distribution (https://github.com/apache/karaf/blob/master/assemblies/docker/build.sh):

./build.sh --from-local-dist --archive ~/path/to/kloud.tar.gz --image-name kloudUsing karaf dist: /home/jbonofre/Workspace/kloud/kloud.tar.gzSending build context to Docker daemon  79.36MBStep 1/10 : FROM java:8-jre-alpine ---> fdc893b19a14Step 2/10 : ENV KARAF_INSTALL_PATH=/opt ---> Running in c48b1e2bf909Removing intermediate container c48b1e2bf909 ---> f6cc4d99d965Step 3/10 : ENV KARAF_HOME $KARAF_INSTALL_PATH/apache-karaf ---> Running in ae61251f9332Removing intermediate container ae61251f9332 ---> 8092cc15e2d3Step 4/10 : ENV PATH $PATH:$KARAF_HOME/bin ---> Running in 9ae9f2ebe44cRemoving intermediate container 9ae9f2ebe44c ---> b107423b2920Step 5/10 : ARG karaf_dist=NOT_SET ---> Running in 15340610bc2dRemoving intermediate container 15340610bc2d ---> 075b9981d66bStep 6/10 : ADD $karaf_dist $KARAF_INSTALL_PATH ---> dee79a14fe7dStep 7/10 : RUN set -x &&   ln -s $KARAF_INSTALL_PATH/apache-karaf* $KARAF_HOME ---> Running in 6f1f292aa5f6+ ln -s /opt/apache-karaf-4.2.1 /opt/apache-karafRemoving intermediate container 6f1f292aa5f6 ---> d2aea8c4ef8eStep 8/10 : COPY docker-entrypoint.sh / ---> 454600e6f558Step 9/10 : EXPOSE 8101 1099 44444 8181 ---> Running in 581aba587bdcRemoving intermediate container 581aba587bdc ---> b4595b7e944dStep 10/10 : ENTRYPOINT ["/docker-entrypoint.sh"] ---> Running in 1f49d86b563cRemoving intermediate container 1f49d86b563c ---> de6ac03845bdSuccessfully built de6ac03845bdSuccessfully tagged kloud:latest

We now have our kloud Karaf Docker image:

$> docker imagesREPOSITORY                                 TAG                 IMAGE ID            CREATED             SIZEkloud                                      latest              de6ac03845bd        58 seconds ago      198MB...

We can run and test our image:

$> docker run -i --name kloud -p 8181:8181 kloudStarting Apache Karaf

We can now the WADL of our REST service available on http://localhost:8181/cxf/booking?_wadl.

So, our Docker image is ready, it’s the one we will push and run on Azure cloud.

Creating Azure container registry

As our image is not available on “public” DockerHub, we will create our container registry on Azure. It’s like DockerHub local to our cloud platform.

First, we create the container registry in Azure resources:

We now have our container registry available:

We can push our kloud Karaf Docker image on this container registry.

Pushing our Karaf Docker image on Azure container registry

First, we login on our Azure container registry. You have to get the credentials from the container:

Now, we logon on the Azure docker from our local docker daemon:

$> docker login -u karaf -p xxxxx karaf.azurecr.ioWARNING! Using --password via the CLI is insecure. Use --password-stdin.Login Succeeded

We can now create a tag and push on karaf.azurecr.io Azure Docker container:

$> docker tag kloud karaf.azurecr.io/kloud$> docker push karaf.azurecr.io/kloudThe push refers to repository [karaf.azurecr.io/kloud]8fc85780c222: Pushed df9688476ce7: Pushed 5e5beed17b78: Pushed 20dd87a4c2ab: Pushed 78075328e0da: Pushed 9f8566ee5135: Pushed latest: digest: sha256:be6ce4c0cf223cf16ebc6f22ce9458828a229214e71d9ba1dd9a1c16daf22bd7 size: 1573

We can see our image on our Azure container registry:

Creating and running container on Azure

Now that our kloud image is on Azure container registry, we can create a Docker container on Azure. It’s named Azure Container instance:

We name our container kloud:

We configure to expose 8181 port number (the default HTTP port number used by Karaf):

We are now ready to create our container (note that we use the Karaf run starting mode as the tty is not bound by default on cloud):

We can see our container startup log:

We can eventually logon on our container:

In the container overview, we can see the load and the IP given to your container:

It means that our REST example service is available on the public IP (http://13.73.183.71:8181/cxf/booking?_wadl for this example container):

It’s also possible to use the DNS we set on the container instance, it means our REST service is available on http://kloud.westeurope.azurecontainer.io:8181/cxf/booking?_wadl:

What’s next ? Azure Kubernetes Service

Now we have all resources available to use Azure Kubernetes Service.

We can have several kloud containers running as Kubernetes POD and create a Kubernetes service for the example REST.

In the next blog post, I will show you how to setup a Kubernetes cluster on Azure and deploy Karaf based applications on it.

Stay tuned !

Comments

Post a Comment

Popular posts from this blog

Quarkus and "meta" extension

Quarkus is a great Java framework with a large ecosystem thanks to the extensions . Basically, if using Maven, your pom.xml contains the list of the extensions you want to use, meaning something like this: ... <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-grpc</artifactId> </dependency> <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-opentelemetry</artifactId> </dependency> ... It can quickly become large, and sometime you can have "conflict" between extensions (for example if you mix in the same dependencies set reactive and non reactive extensions). Quarkus "meta" extension To simplify the dependencies for the extensions you want to use (especially if it's basically the same extensions in all your services), you can create your own "meta" extension. This extension doesn't contain actual code, it "wraps" other exten
Read more

Getting started with Apache Karaf Minho

Image
Apache Karaf Minho Apache Karaf Minho is a new runtime, completely created from scratch. The objectives are: super easy to use and run ligtning fast, including GraalVM support Kubernetes compliant to be easily used on the cloud helping to optimize cloud costs by supporting applications colocation providing turnkey services allowing you to create Minho applications in a minute Minho is composed by: minho-boot is the core of Minho. It contains the runtime launcher and the core services (service registry, lifecycle service, configuration service, ...). minho-* services provided additional functionnalities in the runtime. You can use these services to create your own services, it's also where you will find the services managing sepcific kind of applications, allowing colocation. minho-tooling optionally provide convenient tools to create your own runtime. It includes minho-maven-plugin for instance. In this blog post, we will take a quick tour on A
Read more

Apache Karaf Minho and OpenTelemetry

Image
Telemetry is an important part of a software stack, especially on distributed system (where services call each others). OpenTelemetry is a CNCF project coming from OpenTracing and OpenCensus. It provides API to easily instrument your code and tools to collect and export telemetry data (metrics, logs and traces). Before going into how to use OpenTelemetry with Minho, we have to understand some key concepts: Span is a single building block representing an operation or some unit of work that you want to capture. They are capable of standing on their own, referencing (or following) from other spans, storing metadata, tags, etc. Trace is a visualisation of the life of a request (or series of other operations) that is made up of one or more spans. This collection of spans work together to paint a picture of the overall request, allowing you to easily reconstruct what happened within each span, etc. SpanContext is a wrapper of key values pairs that associates a trace to one or mor
Read more