It appears that you have a fresh installation. How would you like to initialize this node?
meierw opened this issue · 8 comments
Prior to Axon Server 2023.x, whenever I would run Axon server in a container, from the axoniq/axonserver image, it would just work straight away.
Now it's showing this message on first run inside the web console. And doesn't allow connecting to the server right away.
It appears that you have a fresh installation. How would you like to initialize this node?
Would you like to complete the installation and use this node as a standalone node or as the first node in a cluster (Enterprise Edition only), or as a node in an existing cluster?
Action:
Start as standalone node or first node
With context name:
default
Finish
This is an issue, as we relied on the server working right away after boot in many of our dev environments and testcontainers.
What would be a quick solution to the issue? Do I need to include the axonserver.properties file in my container with some extra defaults configured? I couldn't figure from the docs, if this is even possible with config properties.
Hey Walter!
Can you please add the exact tags you have been using? There are two different "styles" available from the repository, with one running in the root ("/") and the other running in "/axonserver". Some images also run as user "axonserver", so it is important to be careful about this. The images marked with "-dev" are of the "/axonserver" variety, while the ones without are of the "/" variety.
As to why this difference exists: the "dev" images are built using the Eclipse Temurin images and support both Intel/AMD as well as ARM processor architectures, while the others use the older "Distroless" images that do not. Given the popularity of ARM silicon nowadays, we need to support that. Also, Distroless had issues with supporting non-root images. During the cleanup involved, we also chose a more secure installation location, preventing any confusion between files belonging to the OS and those of Axon Server.
If this is indeed the problem you are facing, you can either remap your volumes to the new locations or build your own image.
There are properties you can set to make Axon Server initialize itself immediately on first start. These are:
axoniq.axonserver.autocluster.first="your-docker-hostname"
axoniq.axonserver.autocluster.contexts=default
You can add these to the axonserver.properties or add them as environment properties.
Hi @bert-laverman I was using -dev both before and after the version bump to 2023.x. So 4.6.9-dev (worked ok) and then 2023.1.0-dev (has issue mentioned)
@MGathier That indeed looks like what I was searching for. Can you share where in the docs those options can be found? I think I must be blind for missing that.
(Edit) Scratch that I found where in the docs it is. Will try them out.
I work with @meierw, and we've been trying to get Axon Server running smoothly, but we've encountered a roadblock.
Here's the context:
To ensure that Axon Server initializes immediately on first start, we tried adding the following docker compose configuration following the suggestions made:
services:
axonserver:
container_name: axonserver
image: axoniq/axonserver:2023.1.0-dev
ports:
- 8024:8024
- 8124:8124
environment:
- AXONIQ_AXONSERVER_AUTOCLUSTER_FIRST
- AXONIQ_AXONSERVER_AUTOCLUSTER_CONTEXTS=defaultHowever, upon starting the container, we're encountering the following error messages:
axonserver | 2023-07-18 14:24:11.646 INFO 1 --- [ main] i.a.a.enterprise.init.AutoCluster : This de6facaeaeb7:8224 is not the initial node for the cluster, already have 0 other nodes and 0 contexts
axonserver | 2023-07-18 14:24:11.724 WARN 1 --- [task-scheduler1] i.a.a.e.c.internal.ManagedChannelHelper : Error while building channel - Invalid host or port: 8224
axonserver | 2023-07-18 14:24:11.729 WARN 1 --- [task-scheduler1] i.a.a.taskscheduler.BaseTaskManager : _local: Failed to execute task d028daf0-3370-461c-aaa3-2ffe54430091: io.axoniq.axonserver.enterprise.taskscheduler.task.RegisterNodeTask
We are unsure if the configuration we provided is incorrect or if we are missing something important.
If anyone has encountered a similar issue or knows how to resolve this, your guidance would be greatly appreciated. We've tried referring to the Axon Server documentation, but we couldn't find a specific solution.
Thank you in advance for any help you can provide!
Thank you for this report. I can confirm the behavior. I suggest you set the container's hostname explicitly and use that as the value for "AXONIQ_AXONSERVER_AUTOCLUSTER_FIRST." So, add "hostname: axonserver" to your docker-compose file and (assuming you set no domain) use "AXONIQ_AXONSERVER_AUTOCLUSTER_FIRST=axonserver", comparable to:
docker run -d --name axonserver --hostname axonserver -p 8024:8024 -p 8124:8124 -e AXONIQ_AXONSERVER_AUTOCLUSTER_FIRST=axonserver -e AXONIQ_AXONSERVER_AUTOCLUSTER_CONTEXTS=default axoniq/axonserver:2023.1.0-dev
At startup, Axon Server compares this "first" value to its own configured FQDN and will start cluster initialization only if they match. If they do not match, it will attempt to contact the provided host and join its cluster instead, which is a licensed functionality.
This solution is working splendidly! Thank you for your assistance and quick responses.
We have released Axon Server 2023.1.1 with a change to simplify this and resolve issue:
2023.1.1 Update:
To simplify initialization of Axon Server, it now supports a new property “axoniq.axonserver.standalone=true”. When this property is set on a clean Axon Server instance it initializes the server with a “default” context.
No need to set auto cluster properties anymore, in fact, new property should not coexist with auto cluster or cluster template configuration
Nice!. Big thanks, this will make our docker-compose and testcontainer logic a lot neater.