[
https://issues.jboss.org/browse/ISPN-6673?page=com.atlassian.jira.plugin....
]
Sebastian Łaskawiec edited comment on ISPN-6673 at 7/21/16 4:27 AM:
--------------------------------------------------------------------
The procedure for OpenShift looks like the following:
# Start OpenShift cluster using:
{code}
oc cluster up
{code}
Not 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}
was (Author: sebastian.laskawiec):
The procedure for OpenShift looks like the following:
# Start OpenShift cluster using:
{code}
oc cluster up
{code}
Not you are logged as a developer.
# Create new Infinispan cluster using standard configuration:
{code}
oc new-app slaskawi/infinispan-experiments
{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}
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#_Ro...] -
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)