ScaleCube Microservices Dockers
you may find ScaleCube docker images here: Docker repository: Tags
scalecube-seed-[version]..................................................82 MB
scalecube-account-[version]............................................85 MB
scalecube-account-[version]............................................97 MB
scalecube-configuration-[version].................................82 MB
scalecube-configuration-gateway-[version]................97 MB
scalecube-gateway-all-[version]....................................99 MB
when coming to deploy ScaleCube dockers there are many flexible possible configuration of deployments and you should consider the best case for your relevant environment (development, testing, production) based on the required scale.
the pictures bellow shows that its really does not matter where you deploy what service. its purely matter of configuration. using swarm enables the simplification of orchestrating the docker containers over hosts.
ScaleCube Cluster and service registry will create an group membership for the services as long they have network access to remote hosts and are able to communicate. here comes swarm NAT to play.
when any scalecube docker container is starting it first needs to join the cluster using seed nodes make the cluster more predictable as their sole role is to form the cluster and less subject for versioning and upgrades. but in-fact any docker can serve as seed node and any service can join the cluster via any node.
Scalebue cluster members are constantly tracking the service instances in the cluster and will know to route requests based on their availability when new service instance appears/disappears in the membership group it will automatically get into play or excluded from the routes. (read more about scalecube cluster). due to this behavior with scalecube you gain more flexibility when deploying a cluster and more control selecting service instances and endpoints and scaling specific service or entire stack independently.
Seed container is used to establish a cluster membership as well known entry point to any cluster members wish to join the cluster. When a new member is started it sends to all seed nodes SYNC message in order to synchronize membership tables until one of them answers, if all failed to answer it is decided that this member is the first member in the cluster.
It is possible to configure any node as a seed member in order to join the cluster, but it is recommended to configure nodes with most probability for maximum up-time so in such case cluster can be restored from network partitioning through SYNC messages with seed members (e.g. API Gateways can serve as a seed members of the cluster or dedicated seed members).
The seed nodes can be started in any order and it is not necessary to have all/or any seed nodes running, but when initially starting a cluster, the cluster will be initialized only when one or more seed-nodes will become initialized else no other node can join the cluster and nodes can only see themselves. Note that you can only join to an existing cluster member, which means that for bootstrapping some node must join itself, and then the following nodes could join them to make up a cluster.
scalecube-seed-[version]
The API gateway abstract the dynamic behavior and complexity of microservices and Docker containers from the clients and consumers - it is the bridge between the internal cluster/services architecture-complexity and the client preferred protocols.
An API gateway is a cluster member that expose service API outside of the docker engine. this is where client specific protocol (example REST/API) is translated to scalecube service requests. its role is to route service requests within a membership group. it might be a specific service in a group or all services in a group. since the api gateway is also a scalecube cluster member its on one hand communicate the service protocol and also a member of the cluster and aware on the cluster membership status at all times. that means it is aware of any failures and changes of cluster status. the api gateway is responsible to decide what API to expose to clients and to govern the service requests while they trying to access the microservices cluster.
Dockers:
scalecube-configuration-gateway-[version]
scalecube-account-gateway-[version]
Account service: implements the account service API and uses redis as persistence storage.
Dockers:
scalecube-account-[version]
Configuration service: implements the configuration API and uses redis as persistence storage.
Dockers:
scalecube-configuration-[version]
Currently development is still at early stage and my be subject to changes: you may find current state dockers: Microservices Tags at docker hub
run a redis instance:
docker run -t redis
run a seed node:
docker run -t ronenna/scalecube:scalecube-seed-0.0.5-SNAPSHOT
run a seed node that joins prev seed node:
docker run -e "SC_SEED_ADDRESS=172.17.0.3:4801" -t ronenna/scalecube:scalecube-seed-0.0.5-SNAPSHOT
run an account service that joins the seed node and connects to the redis ip:
docker run -e "SC_SEED_ADDRESS=172.17.0.3:4801" -e "REDIS_ADDRESS=redis://172.17.0.2:6379" -t ronenna/scalecube:scalecube-account-0.0.5-SNAPSHOT
run a configuration service that joins the seed node and connects to the redis ip:
docker run -e "SC_SEED_ADDRESS=172.17.0.3:4801" -e "REDIS_ADDRESS=redis://172.17.0.2:6379" -t ronenna/scalecube:scalecube-configuration-0.0.5-SNAPSHOT
run account gateway that joins the seed node and expose 8081 port:
docker run -e "SC_SEED_ADDRESS=172.17.0.3:4801" -p 8081:8081 -t ronenna/scalecube:scalecube-account-gateway-0.0.5-SNAPSHOT
run configuration gateway that joins the seed node and expose 8082 port:
docker run -e "SC_SEED_ADDRESS=172.17.0.3:4801" -p 8082:8081 -t ronenna/scalecube:scalecube-configuration-gateway-0.0.5-SNAPSHOT
Run the example Web app main from your development environment:
- io.scalecube.webapp.example.WebApplicationExample.main(args)
- from your browser open http://localhost:8080