Assumptions
The environment consists of four (4) nodes with JLupin Platform installed:
- demoapp1 (10.2.3.11)
- demoapp2 (10.2.3.12)
- demoapp3 (10.2.3.13)
- demoapp4 (10.2.3.14)
and five (5) prepared for deployment microservices: from m1 to m5.
The management tasks is done through centrally hosted JLupin Control Center on Linux type server (separated from JLupin Platform nodes).
Use cases
Creating user with admin privileges
1) Login as 'user_admin' (default password: user_admin)
[demouser@demowww1 ~]$ console
Your username: user_admin
Your password:
+-----------------------------------------------------------+
| Welcome to JLupin Control Center CLI Console 1.6.1.0-beta |
+-----------------------------------------------------------+
NOTICE: The verbose mode is on, if you would like to turned it off please execute 'verbose off' command.
user_admin@/jlupin/zone/default>
2) Create user with proper role (admin)
user_admin@/jlupin/zone/> user create admin1 MASTER_ADMIN
Password:
Repeat password:
user_admin@/jlupin/zone/> user list
Username Role
admin1 MASTER_ADMIN
user_admin USER_ADMIN
Preparing the infrastructure: one zone, four nodes
1) Login with administration privileges:
user_admin@/jlupin/zone/> exit
[demouser@demowww1 ~]$ console
Your username: admin1
Your password:
+-----------------------------------------------------------+
| Welcome to JLupin Control Center CLI Console 1.6.1.0-beta |
+-----------------------------------------------------------+
NOTICE: The verbose mode is on, if you would like to turned it off please execute 'verbose off' command.
admin1@/jlupin/zone/default>
2) Create zone 'zone_a'
admin1@/jlupin/zone/default> zone list
Zone #Nodes
default 0
admin1@/jlupin/zone/default> zone create zone_a
Zone created: zone_a
admin1@/jlupin/zone/default> zone list
Zone #Nodes
default 0
zone_a 0
3) Connect the nodes (demoapp1 - demoapp4):
admin1@/jlupin/zone/default> verbose off
Verbose mode: off
admin1@/jlupin/zone/default> cd ../zone_a
admin1@/jlupin/zone/zone_a> node connect 10.2.3.11
Node connected: demoapp1
admin1@/jlupin/zone/zone_a> node connect 10.2.3.12
Node connected: demoapp2
admin1@/jlupin/zone/zone_a> node connect 10.2.3.13
Node connected: demoapp3
admin1@/jlupin/zone/zone_a> node connect 10.2.3.14
Node connected: demoapp4
admin1@/jlupin/zone/zone_a> zone list
Zone #Nodes
default 0
zone_a 4
admin1@/jlupin/zone/zone_a> node status
Zone Node IP address Status
zone_a demoapp1 10.2.3.11 ENABLED
zone_a demoapp2 10.2.3.12 ENABLED
zone_a demoapp3 10.2.3.13 ENABLED
zone_a demoapp4 10.2.3.14 ENABLED
4) Check the load balancers' configuration:
admin1@/jlupin/zone/zone_a/> node peers
SrcZone SrcNode SrcIPAddress Zone Node IP address Comm Ports
zone_a demoapp1 10.2.3.11 zone_a demoapp1 localhost 9090,9095,9096,9097
zone_a demoapp2 10.2.3.12 zone_a demoapp2 localhost 9090,9095,9096,9097
zone_a demoapp3 10.2.3.13 zone_a demoapp3 localhost 9090,9095,9096,9097
zone_a demoapp4 10.2.3.14 zone_a demoapp4 localhost 9090,9095,9096,9097
It means that none of the microservices on the given node is able to communication through load balancers with microservices located on other nodes (Only local communication is allowed). The zone connect zone_a * zone_a * command updates nodes configuration within the zone to establish full mesh communication pattern.
5) Activate the nodes in the zone zone_a:
admin1@/jlupin/zone/zone_a> zone connect zone_a * zone_a *
demoapp1: Configuration successfully updated
demoapp2: Configuration successfully updated
demoapp3: Configuration successfully updated
demoapp4: Configuration successfully updated
Zone connected.
admin1@/jlupin/zone/zone_a> node peers
SrcZone SrcNode SrcIPAddress Zone Node IP address Comm Ports
zone_a demoapp1 10.2.3.11 zone_a demoapp1 127.0.0.1 9090,9095,9096,9097
zone_a demoapp1 10.2.3.11 zone_a demoapp2 10.2.3.12 9090,9095,9096,9097
zone_a demoapp1 10.2.3.11 zone_a demoapp3 10.2.3.13 9090,9095,9096,9097
zone_a demoapp1 10.2.3.11 zone_a demoapp4 10.2.3.14 9090,9095,9096,9097
zone_a demoapp2 10.2.3.12 zone_a demoapp2 127.0.0.1 9090,9095,9096,9097
zone_a demoapp2 10.2.3.12 zone_a demoapp1 10.2.3.11 9090,9095,9096,9097
zone_a demoapp2 10.2.3.12 zone_a demoapp3 10.2.3.13 9090,9095,9096,9097
zone_a demoapp2 10.2.3.12 zone_a demoapp4 10.2.3.14 9090,9095,9096,9097
zone_a demoapp3 10.2.3.13 zone_a demoapp3 127.0.0.1 9090,9095,9096,9097
zone_a demoapp3 10.2.3.13 zone_a demoapp1 10.2.3.11 9090,9095,9096,9097
zone_a demoapp3 10.2.3.13 zone_a demoapp2 10.2.3.12 9090,9095,9096,9097
zone_a demoapp3 10.2.3.13 zone_a demoapp4 10.2.3.14 9090,9095,9096,9097
zone_a demoapp4 10.2.3.14 zone_a demoapp4 127.0.0.1 9090,9095,9096,9097
zone_a demoapp4 10.2.3.14 zone_a demoapp1 10.2.3.11 9090,9095,9096,9097
zone_a demoapp4 10.2.3.14 zone_a demoapp2 10.2.3.12 9090,9095,9096,9097
zone_a demoapp4 10.2.3.14 zone_a demoapp3 10.2.3.13 9090,9095,9096,9097
Now, every node in the zone is able to communicate with any other node in the zone.
Deploying microservices
We are going to deploy four microservices (m1 - m4) on every node in the zone.
1) Check the current environment's configuration
admin1@/jlupin/zone/zone_a> node list
Zone Name IPAddress Version #Micro
zone_a demoapp1 10.2.3.11 1.0 0
zone_a demoapp2 10.2.3.12 1.0 0
zone_a demoapp3 10.2.3.13 1.0 0
zone_a demoapp4 10.2.3.14 1.0 0
admin1@/jlupin/zone/zone_a> microservice list
Zone Node Microservice Type Version #Services Context
2) Deploy the first microservice (m1)
admin1@/jlupin/zone/zone_a> microservice upload m1.zip *
Uploading zip file m1.zip.
m1@demoapp1: Microservice uploaded correctly.
m1@demoapp2: Microservice uploaded correctly.
m1@demoapp3: Microservice uploaded correctly.
m1@demoapp4: Microservice uploaded correctly.
>> m1.zip <<
>> microserviceName <<
m1
>> nodes <<
>> demoapp1 <<
uploaded: true
>> demoapp2 <<
uploaded: true
>> demoapp3 <<
uploaded: true
>> demoapp4 <<
uploaded: true
3) Check the current environment's configuration and microservice details
admin1@/jlupin/zone/zone_a> microservice list
Zone Node Microservice Type Version #Services Context
zone_a demoapp1 m1 native 1.0 3 /jlupin/zone/zone_a/demoapp1/m1
zone_a demoapp2 m1 native 1.0 3 /jlupin/zone/zone_a/demoapp2/m1
zone_a demoapp3 m1 native 1.0 3 /jlupin/zone/zone_a/demoapp3/m1
zone_a demoapp4 m1 native 1.0 3 /jlupin/zone/zone_a/demoapp4/m1
admin1@/jlupin/zone/zone_a> microservice status
Zone Node Microservice ProcessID Status Available Activated
zone_a demoapp1 m1 5001 STOPPED* no yes
zone_a demoapp2 m1 5002 STOPPED* no yes
zone_a demoapp3 m1 5003 STOPPED* no yes
zone_a demoapp4 m1 5004 STOPPED* no yes
admin1@/jlupin/zone/zone_a> microservice details m1
Zone Node Microservice Service
zone_a demoapp1 m1 animalsRMCSeleuciaService
zone_a demoapp1 m1 animalsROASeleuciaService
zone_a demoapp1 m1 digestService
4) Start the m1 microservice on all nodes
admin1@/jlupin/zone/zone_a> microservice start m1
Are you sure you want to start microservice 'm1' on all nodes in the zone 'zone_a'? (Y/N): y
Updating microservices on demoapp1:
m1@demoapp1: Microservice started correctly.
Updating microservices on demoapp2:
m1@demoapp2: Microservice started correctly.
Updating microservices on demoapp3:
m1@demoapp3: Microservice started correctly.
Updating microservices on demoapp4:
m1@demoapp4: Microservice started correctly.
>> m1@demoapp1 <<
started: yes
>> m1@demoapp2 <<
started: yes
>> m1@demoapp3 <<
started: yes
>> m1@demoapp4 <<
started: yes
admin1@/jlupin/zone/zone_a> microservice status m1
Zone Node Microservice ProcessID Status Available Activated
zone_a demoapp1 m1 5001 RUNNING no yes
zone_a demoapp2 m1 5002 RUNNING no yes
zone_a demoapp3 m1 5003 RUNNING no yes
zone_a demoapp4 m1 5004 RUNNING no yes
5) Deploy the rest of the microservices (m2-m4) - follow the instructions from point 2 to 4 for each microservice.
6) Check the current environment's configuration after deployment
admin1@/jlupin/zone/zone_a> microservice status
Zone Node Microservice ProcessID Status Available Activated
zone_a demoapp1 m1 5001 RUNNING no yes
zone_a demoapp1 m2 5002 RUNNING no yes
zone_a demoapp1 m3 5003 RUNNING no yes
zone_a demoapp1 m4 5004 RUNNING no yes
zone_a demoapp2 m1 5005 RUNNING no yes
zone_a demoapp2 m2 5006 RUNNING no yes
zone_a demoapp2 m3 5007 RUNNING no yes
zone_a demoapp2 m4 5008 RUNNING no yes
zone_a demoapp3 m1 5009 RUNNING no yes
zone_a demoapp3 m2 5010 RUNNING no yes
zone_a demoapp3 m3 5011 RUNNING no yes
zone_a demoapp3 m4 5012 RUNNING no yes
zone_a demoapp4 m1 5013 RUNNING no yes
zone_a demoapp4 m2 5014 RUNNING no yes
zone_a demoapp4 m3 5015 RUNNING no yes
zone_a demoapp4 m4 5016 RUNNING no yes
Maintenance tasks
1) Check node's configuration
admin1@/jlupin/zone/zone_a> goto demoapp1/
admin1@/jlupin/zone/zone_a/demoapp1> show
>> ATTRIBUTES <<
objectType: node
name: demoapp1
address: 10.2.3.11
type: static
context: /jlupin/zone/zone_a/demoapp1
transmissionPort: 9096
>> RUNTIME <<
status: ENABLED
jvmFreeMemory: 0.08 GB
jvmMaxMemory: 0.22 GB
jvmProcessCpuLoad: 3.0
jvmTotalMemory: 0.12 GB
>> CONFIGURATION <<
MAIN_SERVER:location: DC1
2) Check microservice's configuration
admin1@/jlupin/zone/zone_a/demoapp1> cd m1
admin1@/jlupin/zone/zone_a/demoapp1/m1> show
>> ATTRIBUTES <<
objectType: microservice
name: m1
type: dynamic
context: /jlupin/zone/zone_a/demoapp1/m1
>> RUNTIME <<
microType: native
status: RUNNING
isAvailable: yes
jlrmcActiveThreads: 0
jlrmcMaxThreads: 8
jvmFreeMemory: 0.05 GB
jvmMaxMemory: 0.11 GB
jvmProcessCpuLoad: 0.1
jvmTotalMemory: 0.08 GB
pid: 5001
queueActiveThreads: 0
queueMaxThreads: 8
servicePort: 20000
servletActiveThreads: N/A
servletMaxThreads: N/A
3) Show specific parameter
admin1@/jlupin/zone/zone_a/demoapp1/m1> show RUNTIME:jvmProcessCpuLoad
jvmProcessCpuLoad: 0.0
4) Change the number of threads for JRMC and memory for JVM
admin1@/jlupin/zone/zone_a/demoapp1/m1> show CONFIGURATION:SERVERS:JLRMC_BINARY:threadPoolSize
SERVERS:JLRMC_BINARY:threadPoolSize: 128
admin1@/jlupin/zone/zone_a/demoapp1/m1> show CONFIGURATION:PROPERTIES:jvmOptions1
PROPERTIES:jvmOptions1: -Xms64M -Xmx128M -Dlog4j.configurationFile=${sys:microservice.dir}/log4j2.xml
admin1@/jlupin/zone/zone_a/demoapp1/m1> set CONFIGURATION:SERVERS:JLRMC_BINARY:threadPoolSize to 256
Attribute CONFIGURATION:SERVERS:JLRMC_BINARY:threadPoolSize set to 256 for object /jlupin/zone/zone_a/demoapp1/m1.
admin1@/jlupin/zone/zone_a/demoapp1/m1> set CONFIGURATION:PROPERTIES:jvmOptions1 to "-Xms256M -Xmx384M-Dlog4j.configurationFile=${sys:microservice.dir}/log4j2.xml"
Attribute CONFIGURATION:PROPERTIES:jvmOptions1 set to -Xms256M -Xmx384M-Dlog4j.configurationFile=${sys:microservice.dir}/log4j2.xml for object /jlupin/zone/zone_a/demoapp1/m1.
admin1@/jlupin/zone/zone_a/demoapp1/m1> microservice restart
Updating microservices on demoapp1:
m1@demoapp1: Microservice restarted correctly.
>> m1@demoapp1 <<
restarted: yes
admin1@/jlupin/zone/zone_a/demoapp1/m1> CONFIGURATION:SERVERS:JLRMC_BINARY:threadPoolSize
SERVERS:JLRMC_BINARY:threadPoolSize: 256
admin1@/jlupin/zone/zone_a/demoapp1/m1> show CONFIGURATION:PROPERTIES:jvmOptions1
PROPERTIES:jvmOptions1: -Xms256M -Xmx384M -Dlog4j.configurationFile=${sys:microservice.dir}/log4j2.xml
5) Upgrade the m1 microservice
Let's assume that we have a new version of m1 microservice archived as m1.zip. We want to deploy it carefully that's why the new version initially will be implemented on one node (ex. demoapp1) and after checking the state of the application (out of the scope of this documentation) - on the rest nodes in the zone.
admin1@/jlupin/zone/zone_a/demoapp1/m1> cd ..
admin1@/jlupin/zone/zone_a/demoapp1> cd ..
admin1@/jlupin/zone/zone_a> microservice status m1
Zone Node Microservice ProcessID Status Available Activated
zone_a demoapp1 m1 5001 RUNNING no yes
zone_a demoapp2 m1 5002 RUNNING no yes
zone_a demoapp3 m1 5003 RUNNING no yes
zone_a demoapp4 m1 5004 RUNNING no yes
admin1@/jlupin/zone/zone_a> microservice upload m1.zip demoapp1
Uploading zip file m1.zip.
m1@demoapp1: Microservice uploaded correctly.
>> m1.zip <<
>> microserviceName <<
m1
>> nodes <<
>> demoapp1 <<
uploaded: true
admin1@/jlupin/zone/zone_a> microservice status m1
Zone Node Microservice ProcessID Status Available Activated
zone_a demoapp1 m1 5001 RUNNING* no yes
zone_a demoapp2 m1 5002 RUNNING no yes
zone_a demoapp3 m1 5003 RUNNING no yes
zone_a demoapp4 m1 5004 RUNNING no yes
The asterisk near the status means that the version of the microservice has been changed. Now we should restart the m1 microservice to activate new version. It will be done completely online due to zero downtime deployment mechanisms.
admin1@/jlupin/zone/zone_a> microservice restart m1 demoapp1
Updating microservices on demoapp1:
m1@demoapp1: Microservice restarted correctly.
>> m1@demoapp1 <<
restarted: yes
admin1@/jlupin/zone/zone_a> microservice status m1
Zone Node Microservice ProcessID Status Available Activated
zone_a demoapp1 m1 5001 RUNNING no yes
zone_a demoapp2 m1 5002 RUNNING no yes
zone_a demoapp3 m1 5003 RUNNING no yes
zone_a demoapp4 m1 5004 RUNNING no yes
(Testing new version)
admin1@/jlupin/zone/zone_a> microservice upload m1.zip demoapp2
Uploading zip file m1.zip.
m1@demoapp2: Microservice uploaded correctly.
>> m1.zip <<
>> microserviceName <<
m1
>> nodes <<
>> demoapp2 <<
uploaded: true
admin1@/jlupin/zone/zone_a> microservice upload m1.zip demoapp3
Uploading zip file m1.zip.
m1@demoapp3: Microservice uploaded correctly.
>> m1.zip <<
>> microserviceName <<
m1
>> nodes <<
>> demoapp3 <<
uploaded: true
admin1@/jlupin/zone/zone_a> microservice upload m1.zip demoapp4
Uploading zip file m1.zip.
m1@demoapp4: Microservice uploaded correctly.
>> m1.zip <<
>> microserviceName <<
m1
>> nodes <<
>> demoapp4 <<
uploaded: true
admin1@/jlupin/zone/zone_a> microservice status m1
Zone Node Microservice ProcessID Status Available Activated
zone_a demoapp1 m1 5001 RUNNING no yes
zone_a demoapp2 m1 5002 RUNNING* no yes
zone_a demoapp3 m1 5003 RUNNING* no yes
zone_a demoapp4 m1 5004 RUNNING* no yes
admin1@/jlupin/zone/zone_a> microservice restart m1
Are you sure you want to restart microservice 'm1' on all nodes in the zone 'zone_a'? (Y/N): y
Updating microservices on demoapp1:
m1@demoapp1: Microservice restarted correctly.
Updating microservices on demoapp2:
m1@demoapp2: Microservice restarted correctly.
Updating microservices on demoapp3:
m1@demoapp3: Microservice restarted correctly.
Updating microservices on demoapp4:
m1@demoapp4: Microservice restarted correctly.
>> m1@demoapp1 <<
restarted: yes
>> m1@demoapp2 <<
restarted: yes
>> m1@demoapp3 <<
restarted: yes
>> m1@demoapp4 <<
restarted: yes
admin1@/jlupin/zone/zone_a> microservice status m1
Zone Node Microservice ProcessID Status Available Activated
zone_a demoapp1 m1 5001 RUNNING no yes
zone_a demoapp2 m1 5002 RUNNING no yes
zone_a demoapp3 m1 5003 RUNNING no yes
zone_a demoapp4 m1 5004 RUNNING no yes
Automation
1) Create a script file containing the list of commands that you would like to execute in one step. In this use case the goal to upgrade the m2 microservices automatically
jcc_script:
interactive off
verbose off
cd /jlupin/zone/zone_a
microservice upload m2.zip *
microservice restart m2
microservice status m2
And then use 'script run' to execute it:
admin1@/jlupin/zone/> script run jcc_script
Interactive mode: off
Verbose mode: off
Uploading zip file m2.zip.
m2@demoapp1: Microservice uploaded correctly.
m2@demoapp2: Microservice uploaded correctly.
m2@demoapp3: Microservice uploaded correctly.
m2@demoapp4: Microservice uploaded correctly.
>> m2.zip <<
>> microserviceName <<
m2
>> nodes <<
>> demoapp1 <<
uploaded: true
>> demoapp2 <<
uploaded: true
>> demoapp3 <<
uploaded: true
>> demoapp4 <<
uploaded: true
Updating microservices on demoapp1:
m2@demoapp1: Microservice restarted correctly.
Updating microservices on demoapp2:
m2@demoapp2: Microservice restarted correctly.
Updating microservices on demoapp3:
m2@demoapp3: Microservice restarted correctly.
Updating microservices on demoapp4:
m2@demoapp4: Microservice restarted correctly.
>> m2@demoapp1 <<
restarted: yes
>> m2@demoapp2 <<
restarted: yes
>> m2@demoapp3 <<
restarted: yes
>> m2@demoapp4 <<
restarted: yes
Zone Node Microservice ProcessID Status Available Activated
zone_a demoapp1 m2 5001 RUNNING no yes
zone_a demoapp2 m2 5002 RUNNING no yes
zone_a demoapp3 m2 5003 RUNNING no yes
zone_a demoapp4 m2 5004 RUNNING no yes
2) You can also execute commands (and scripts) in non-interactive mode using command-console tool, for example for monitoring purposes. In this case we definitely recommend to create username with minimal privileges (in this example: username = oper1, role = viewer).
[demouser@demowww1 ~]$ console -cm -u oper1 -p <password> show RUNTIME:jvmProcessCpuLoad /jlupin/zone/zone_a/demoapp1/m1
jvmProcessCpuLoad: 0.1
3) You can also execute 'script run' command using command-console.
[demouser@demowww1 ~]$ console -cm -u admin1 -p <password> script run jcc_script
Interactive mode: off
Verbose mode: off
Uploading zip file m2.zip.
m2@demoapp1: Microservice uploaded correctly.
m2@demoapp2: Microservice uploaded correctly.
m2@demoapp3: Microservice uploaded correctly.
m2@demoapp4: Microservice uploaded correctly.
>> m2.zip <<
>> microserviceName <<
m2
>> nodes <<
>> demoapp1 <<
uploaded: true
>> demoapp2 <<
uploaded: true
>> demoapp3 <<
uploaded: true
>> demoapp4 <<
uploaded: true
Updating microservices on demoapp1:
m2@demoapp1: Microservice restarted correctly.
Updating microservices on demoapp2:
m2@demoapp2: Microservice restarted correctly.
Updating microservices on demoapp3:
m2@demoapp3: Microservice restarted correctly.
Updating microservices on demoapp4:
m2@demoapp4: Microservice restarted correctly.
>> m2@demoapp1 <<
restarted: yes
>> m2@demoapp2 <<
restarted: yes
>> m2@demoapp3 <<
restarted: yes
>> m2@demoapp4 <<
restarted: yes
Zone Node Microservice ProcessID Status Available Activated
zone_a demoapp1 m2 5001 RUNNING no yes
zone_a demoapp2 m2 5002 RUNNING no yes
zone_a demoapp3 m2 5003 RUNNING no yes
zone_a demoapp4 m2 5004 RUNNING no yes