Hazelcast isn't strictly a process in itself, rather it is a collection of threads that run in a JVM process.
If you download Hazelcast and use the "start.sh" script, it starts a process that only contains Hazelcast
If you use Spring Boot and you have a HazelcastInstance @Bean, Spring Boot will start this bean and stop the bean as part of the JVM lifecycle.
In all cases you can add other code and other threads to the JVM, so it'll contain Hazelcast and something else.
You can even run two or more Hazelcasts in the one JVM process, useful sometimes for testing.
As a Spring Boot user, you will probably find it easier to let Spring Boot launch your application and Hazelcast -- this would be my personal
recommendation but it's more a matter of choice/preference than any compelling need.
If you are new to Docker, you will no doubt have a view of Kubernetes as next, and this brings us to configuration.
For code configuration, I (personally) use a @Bean of type "com.hazelcast.config.Config", and in this bean,
check the Spring environment to determine if running in Kubernetes and to use the Kubernetes discovery,
or not and to use the TCP discovery.
TCP discovery works whether you are in Docker or not, but one item that everyone trips on with Docker is networking. Inside the Docker container the process will see
one IP address but from the outside of the container it may differ. Check the system property "hazelcast.local.publicAddress"
which enables a form of NATting.
Neil