[infinispan-issues] [JBoss JIRA] (ISPN-6673) Implement Rolling Upgrades with Kubernetes
Sebastian Łaskawiec (JIRA)
issues at jboss.org
Thu Jul 21 04:51:04 EDT 2016
[ https://issues.jboss.org/browse/ISPN-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268531#comment-13268531 ]
Sebastian Łaskawiec edited comment on ISPN-6673 at 7/21/16 4:50 AM:
--------------------------------------------------------------------
THESE ARE WORK IN PROGRESS NOTES
The procedure for OpenShift looks like the following:
# Start OpenShift cluster using:
{code}
oc cluster up
{code}
Note you are logged as a developer.
# Create new Infinispan cluster using standard configuration:
{code}
oc new-app slaskawi/infinispan-experiments
{code}
# Node that you should always be using labels for your clusters. I'll call my cluster=cluster-1
{code}
oc env dc/infinispan-experiments OPENSHIFT_KUBE_PING_LABELS=cluster=cluster-1
oc label dc/infinispan-experiments cluster=cluster-1
{code}
# Scale up the deployment
{code}
oc scale dc/infinispan-experiments --replicas=3
{code}
# Create a route to the service
{code}
oc expose svc/infinispan-experiments
{code}
# Add some entries using REST
{code}
curl -X POST -H 'Content-type: text/xml' -d 'test' http://infinispan-experiments-myproject.192.168.0.17.xip.io/rest/default/1
{code}
# Now we can spin up a new cluster. Again, it's very important to use labels which will avoid joining those two clusters together. In my case (just a POC) I will simply export the build configuration and import it back again. However in Production environment you will probably have some changes in your Docker image.
{code}
oc export -o yaml dc/infinispan-experiments > dc_2.yaml
.. edit the name and labels ..
oc create -f dc_2.yaml
{code}
# Now let's verify if everything looks good:
{code}
oc status -v
In project My Project (myproject) on server https://192.168.0.17:8443
http://infinispan-experiments-myproject.192.168.0.17.xip.io to pod port 8080-tcp (svc/infinispan-experiments)
dc/infinispan-experiments deploys istag/infinispan-experiments:latest
deployment #3 deployed 7 minutes ago - 1 pod
deployment #2 deployed 8 minutes ago
deployment #1 deployed 38 minutes ago
dc/infinispan-experiments-2 deploys istag/infinispan-experiments:latest
deployment #1 running for 12 seconds - 1 pod
{code}
# Now we need to expose a service
{code}
oc expose dc/infinispan-experiments-2
{code}
# At this point we have 2 clusters (the old one with selector {{cluster=cluster-1}} and the new one with selector {{cluster=cluster-2}}). Depending on our client we might want (or not) to expose a route to {{svc/infinispan-experiments-2}} or we are good with just a service.
# Since the [Infinispan Upgrade Procedure|http://infinispan.org/docs/stable/user_guide/user_guide.html#_Rolling_chapter] requires port {{4444}} we need to edit the service in source cluster and add it:
{code}
$ oc edit svc/infinispan-experiments
.. add port 4444 ..
{code}
# Get the IP address for source cluster service ({{svc/infinispan-experiments}})
{code}
oc describe svc/infinispan-experiments
.. write down: IP: 172.30.66.108 ..
{code}
The connection string for the cluster will be {{jmx://172.30.66.108:4444/clustered/default}}
#
was (Author: sebastian.laskawiec):
THIS ARE WORK IN PROGRESS NOTES
The procedure for OpenShift looks like the following:
# Start OpenShift cluster using:
{code}
oc cluster up
{code}
Note you are logged as a developer.
# Create new Infinispan cluster using standard configuration:
{code}
oc new-app slaskawi/infinispan-experiments
{code}
# Node that you should always be using labels for your clusters. I'll call my cluster=cluster-1
{code}
oc env dc/infinispan-experiments OPENSHIFT_KUBE_PING_LABELS=cluster=cluster-1
oc label dc/infinispan-experiments cluster=cluster-1
{code}
# Scale up the deployment
{code}
oc scale dc/infinispan-experiments --replicas=3
{code}
# Create a route to the service
{code}
oc expose svc/infinispan-experiments
{code}
# Add some entries using REST
{code}
curl -X POST -H 'Content-type: text/xml' -d 'test' http://infinispan-experiments-myproject.192.168.0.17.xip.io/rest/default/1
{code}
# Now we can spin up a new cluster. Again, it's very important to use labels which will avoid joining those two clusters together. In my case (just a POC) I will simply export the build configuration and import it back again. However in Production environment you will probably have some changes in your Docker image.
{code}
oc export -o yaml dc/infinispan-experiments > dc_2.yaml
.. edit the name and labels ..
oc create -f dc_2.yaml
{code}
# Now let's verify if everything looks good:
{code}
oc status -v
In project My Project (myproject) on server https://192.168.0.17:8443
http://infinispan-experiments-myproject.192.168.0.17.xip.io to pod port 8080-tcp (svc/infinispan-experiments)
dc/infinispan-experiments deploys istag/infinispan-experiments:latest
deployment #3 deployed 7 minutes ago - 1 pod
deployment #2 deployed 8 minutes ago
deployment #1 deployed 38 minutes ago
dc/infinispan-experiments-2 deploys istag/infinispan-experiments:latest
deployment #1 running for 12 seconds - 1 pod
{code}
# Now we need to expose a service
{code}
oc expose dc/infinispan-experiments-2
{code}
# At this point we have 2 clusters (the old one with selector {{cluster=cluster-1}} and the new one with selector {{cluster=cluster-2}}). Depending on our client we might want (or not) to expose a route to {{svc/infinispan-experiments-2}} or we are good with just a service.
# Since the [Infinispan Upgrade Procedure|http://infinispan.org/docs/stable/user_guide/user_guide.html#_Rolling_chapter] requires port {{4444}} we need to edit the service in source cluster and add it:
{code}
$ oc edit svc/infinispan-experiments
.. add port 4444 ..
{code}
# Get the IP address for source cluster service ({{svc/infinispan-experiments}})
{code}
oc describe svc/infinispan-experiments
.. write down: IP: 172.30.66.108 ..
{code}
The connection string for the cluster will be {{jmx://172.30.66.108:4444/clustered/default}}
#
> Implement Rolling Upgrades with Kubernetes
> ------------------------------------------
>
> Key: ISPN-6673
> URL: https://issues.jboss.org/browse/ISPN-6673
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cloud Integrations
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
>
> There are 2 mechanisms which seems to do the same but are totally different:
> * [Kubernetes Rolling Update|http://kubernetes.io/docs/user-guide/rolling-updates/] - replaces Pods in controllable fashon
> * [Infinispan Rolling Updgrate|http://infinispan.org/docs/stable/user_guide/user_guide.html#_Rolling_chapter] - a procedure for upgrading Infinispan or changing the configuration
> Kubernetes Rolling Updates can be used very easily for changing the configuration however if changes are not runtime-compatible, one might loss data. Potential way to avoid this is to use a Cache Store. All other changes must be propagated using Infinispan Rolling Upgrade procedure.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
More information about the infinispan-issues
mailing list