Source: dzone.com
Running Axon Server in DockerCategory: Deployment, Data, Kubernetes, Docker, containerization, github, yaml, shell
In my previous post, I showed you how to run Axon Server locally and configure it for secure operations.
This time around we’ll look at running it in Docker, both using the public image up on Docker Hub as well as with a locally built image, and why you might want to do that.
Important to note here is that this is a pretty basic descriptor in the sense that it does not have any settings for the amount of memory and/or CPU to reserve for Axon Server, which you may want to do for long-running deployments, and it “just” claims 5GiB of disk space for the Event Store.
We can create them directly from their respective files: In the descriptor we now have to announce the secret, add a volume for it, and mount the secret on the volume: Becomes: Then a list of volumes has to be added to link the actual license and properties: It is arguable that the properties should also be in a secret, which tightens up security on the settings in there, but I’ll leave that “as an exercise for the reader.”
In the context of a Docker or Kubernetes deployment this poses a double issue: As a kind of obvious first one, we want to ensure that the volume is persistent, and that we have direct access to it to enable us to make backups.
This time around we’ll look at running it in Docker, both using the public image up on Docker Hub as well as with a locally built image, and why you might want to do that.
Important to note here is that this is a pretty basic descriptor in the sense that it does not have any settings for the amount of memory and/or CPU to reserve for Axon Server, which you may want to do for long-running deployments, and it “just” claims 5GiB of disk space for the Event Store.
We can create them directly from their respective files: In the descriptor we now have to announce the secret, add a volume for it, and mount the secret on the volume: Becomes: Then a list of volumes has to be added to link the actual license and properties: It is arguable that the properties should also be in a secret, which tightens up security on the settings in there, but I’ll leave that “as an exercise for the reader.”
In the context of a Docker or Kubernetes deployment this poses a double issue: As a kind of obvious first one, we want to ensure that the volume is persistent, and that we have direct access to it to enable us to make backups.
Related Articles
Community Partners
DevOps Careers