Infinispan's new image

Infinispan 10 introduced a new server, which does not utilise the same launch commands and configuration as the legacy 9.4 wildfly based server. Therefore, we decided that this was an excellent opportunity to rewrite our container image from scratch to better suite the capabilities of the new server and to provide all the functionality required by the Infinispan Operator.

This post focuses on the server image’s architecture. Future blog posts will focus on more advanced configurations, as well as example usage and deployment scenarios such as deploying a cluster using Kubernetes StatefulSets.

Show me the code!

The source code for the Infinispan image has a new home. The image can be found at https://github.com/infinispan/infinispan-images. Currently this repository only contains the server image, however our intention is for this to also be the home for all future Infinispan related images.

Where’s the Dockerfile?

The most noticable change when looking at the repository is that there is no Dockerfile in the source tree. This is because we decided to utilise the open-source tool CEKit to build our images. CEKit is an image creation tool that allows container images to be created using multiple build engines (e.g. docker, Buildah, Podman) with a single configuration. Installation instructions can be found here, but the basic command to create a Docker based image is as follows.

cekit build docker

CEKit leverages .yaml files for all configuration, opposed to a Dockerfile, as this allows for build time overriding of image properties. For example, with CEKit it’s possible to override the server artifact version without modifying any files, instead the following is passed as a build parameter.

cekit build --overrides '{"artifacts": [{"name": "server.zip", "path": "infinispan-server-10.0.0-SNAPSHOT.zip"}]}' docker

More detailed instructions about how to build the server image from source can be found in the image’s documentation.

Ok so where can I get a pre-built image?

Previously the Infinispan images were deployed exclusively under the jboss namespace at jboss/infinispan-server, however this repository has now been deprecated and will be removed eventually.

Instead, all Infinispan images will now be released under the infinispan namespace and are hosted at both Quay.io and Docker Hub, as quay.io/infinispan/server and infinispan/server.

Getting Started

To get started with infinispan server on your local machine simply execute:

docker run -p 11222:11222 infinispan/server

By default the image has authentication enabled on all exposed endpoints. When executing the above command the image automatically generates a username/password combo, prints the values to stdout and then starts the Infinispan server with the authenticated Hotrod and Rest endpoints exposed on port 11222. Therefore, it’s necessary to utilise the printed credentials when attempting to access the exposed endpoints via clients.

It’s also possible to provide a username/password combination via environment variables like so:

docker run -p 11222:11222 -e USER="Titus Bramble" -e PASS="Shambles" infinispan/server

Connecting via Hotrod

Using the credentials passed in the command above, it is now possible to connect via the HotRod client using the following hotrod-client.properties file. Note, that the following SASL properties must be configured on your client, with the username and password properties changed as required, otherwise the connection will fail:

infinispan.remote.auth-realm=default
infinispan.remote.auth-server-name=infinispan
infinispan.remote.auth-username=Titus Bramble
infinispan.remote.auth-password=Shambles

Connecting via REST

The REST endpoint is configured to utilise the DIGEST protocol, therefore it’s necessary for the HTTP client to authenticate requests. For example, the name of all caches can be retrieved via the following curl command:

 curl --digest -u "Titus Bramble:Shambles" http://localhost:11222/rest/v2/cache

Further Reading

For more detailed information abou how to use the image, please consult the official documentation.

In the next blog post we will look at how the server can be configured for more advanced use-cases by supplying configuration and identity .yaml files.

Get it, Use it, Ask us!

Please download, report bugs, chat with us, ask questions on StackOverflow.

News

Tags

JUGs alpha as7 asymmetric clusters asynchronous beta c++ cdi chat clustering community conference configuration console data grids data-as-a-service database devoxx distributed executors docker event functional grouping and aggregation hotrod infinispan java 8 jboss cache jcache jclouds jcp jdg jpa judcon kubernetes listeners meetup minor release off-heap openshift performance presentations product protostream radargun radegast recruit release release 8.2 9.0 final release candidate remote query replication queue rest query security spring streams transactions vert.x workshop 8.1.0 API DSL Hibernate-Search Ickle Infinispan Query JP-QL JSON JUGs JavaOne LGPL License NoSQL Open Source Protobuf SCM administration affinity algorithms alpha amazon anchored keys annotations announcement archetype archetypes as5 as7 asl2 asynchronous atomic maps atomic objects availability aws beer benchmark benchmarks berkeleydb beta beta release blogger book breizh camp buddy replication bugfix c# c++ c3p0 cache benchmark framework cache store cache stores cachestore cassandra cdi cep certification cli cloud storage clustered cache configuration clustered counters clustered locks codemotion codename colocation command line interface community comparison compose concurrency conference conferences configuration console counter cpp-client cpu creative cross site replication csharp custom commands daas data container data entry data grids data structures data-as-a-service deadlock detection demo deployment dev-preview development devnation devoxx distributed executors distributed queries distribution docker documentation domain mode dotnet-client dzone refcard ec2 ehcache embedded embedded query equivalence event eviction example externalizers failover faq final fine grained flags flink full-text functional future garbage collection geecon getAll gigaspaces git github gke google graalvm greach conf gsoc hackergarten hadoop hbase health hibernate hibernate ogm hibernate search hot rod hotrod hql http/2 ide index indexing india infinispan infinispan 8 infoq internationalization interoperability interview introduction iteration javascript jboss as 5 jboss asylum jboss cache jbossworld jbug jcache jclouds jcp jdbc jdg jgroups jopr jpa js-client jsr 107 jsr 347 jta judcon kafka kubernetes lambda language learning leveldb license listeners loader local mode lock striping locking logging lucene mac management map reduce marshalling maven memcached memory migration minikube minishift minor release modules mongodb monitoring multi-tenancy nashorn native near caching netty node.js nodejs non-blocking nosqlunit off-heap openshift operator oracle osgi overhead paas paid support partition handling partitioning performance persistence podcast presentation presentations protostream public speaking push api putAll python quarkus query quick start radargun radegast react reactive red hat redis rehashing releaase release release candidate remote remote events remote query replication rest rest query roadmap rocksdb ruby s3 scattered cache scripting second level cache provider security segmented server shell site snowcamp spark split brain spring spring boot spring-session stable standards state transfer statistics storage store store by reference store by value streams substratevm synchronization syntax highlighting tdc testing tomcat transactions tutorial uneven load user groups user guide vagrant versioning vert.x video videos virtual nodes vote voxxed voxxed days milano wallpaper websocket websockets wildfly workshop xsd xsite yarn zulip
Posted by Ryan Emerson on 2019-12-02
Tags: docker
back to top