<p>Modern way to achieve seamless roll-out in this scenario is not on the load balancing (i.e. haproxy) side, but instead via proper deployment planning, backward compatibility and/or feature flags.</p>
<p>The issue with load-balancer tinkering is that in the end of day even if you get sticky sessions right it's not going to solve your problem. The reason for that - imagine a user that opened your app in a browser with old react. Underneath, you deploy new java back-end. If the user doesn't reload her browser - she's still going to use old react app with new back-end no matter what (just because javascript is already loaded to the browser).</p>
<p>Instead, look at following example how you can achieve it using API versioning:</p>
<ul>
<li>Let's assume that data model on one of your api end-points is going to change</li>
<li>Let's say your old api was /v1 (or even un-versioned)</li>
</ul>
<p>Here is how you can solve it:</p>
<ol>
<li>You create /v2 version of your api, register /v2 version in your react app</li>
<li>Your latest java back-end needs to still have both /v1 and /v2</li>
<li>You first deploy all java back-ends to your back-end deployment with /v2 support (all your UI is still /v1 - but this is fine, because latest back-end supports it)</li>
<li>Once all back-ends are deployed, you can start roll-out of your UI deployment with latest image (again, experience is seamless since all back-ends support both /v1 and /v2)</li>
</ol>
<p>As you can see, in the above approach, version conflict is avoided and experience is seamless.</p>
<p>P.s. You might want to consider splitting your docker image in 2 - it's a little odd to have a multi-purpose image with 2 entrypoints. There may be little justification for this design.</p>

CC BY-SA 4.0
2020-07-17T03:42:27.730Z
I agree with @toledor. The usual use case when it comes to microservices is that you keep your deployable as minimal in size as possible with many instances as needed. This is something that K8S handles very well and is suited for the purpose. Best practice is to have 1 deployment for each service. That way you can control your entrypoint better too.
Karthik Venkatesan
CC BY-SA 4.0
2020-07-16T12:43:45.270Z
2020-07-16T12:43:45.270Z
taleodor
<p>My team (full stack) team develops single-page web applications using react as a client and spring-boot java apps as back-end.</p>
<p>We deploy the applications on kubernetes. However, we have troubles making rolling updates of the kubernetes pods seamless. Here's our packaging / deployment process:</p>
<ol>
<li>The CI pipeline builds a docker images packaging the java application as an executable jar file and the compile javascript/css assets that form the react client.</li>
<li>That image has 2 entry points: one for starting the jar file (java back-end) and one which starts an nginx that serves the client assets (js/css).</li>
<li>A haproxy cluster routes requests based on URL paths to either nginx or the java back-end.</li>
</ol>
<p>This approach works fine so far.</p>
<p>However, during a rolling update, there will be a number of pods with an &quot;old&quot; java back-end. This leads to the situation that clients with a newly deployed version of the react client
make requests to old java back-ends, because haproxy simply routes api traffic to any available java backend.</p>
<p>As i understand haproxy seems to have support for sticky-backends based on some rules, but this defeats the purpose of having a cluster of backends for load-balancing.</p>
<p>How do others tackle this problem?</p>

<kubernetes><continuous-deployment>
Deploying a single-page web application with a java backend on kubernetes and haproxy
pulse00
# Deploying a single-page web application with a java backend on kubernetes and haproxy

(Asked by: username_0 on 2020-07-16)

My team (full stack) team develops single-page web applications using react as a client and spring-boot java apps as back-end.

We deploy the applications on kubernetes. However, we have troubles making rolling updates of the kubernetes pods seamless. Here's our packaging / deployment process:

1. The CI pipeline builds a docker images packaging the java application as an executable jar file and the compile javascript/css assets that form the react client.
2. That image has 2 entry points: one for starting the jar file (java back-end) and one which starts an nginx that serves the client assets (js/css).
3. A haproxy cluster routes requests based on URL paths to either nginx or the java back-end.

This approach works fine so far.

However, during a rolling update, there will be a number of pods with an "old" java back-end. This leads to the situation that clients with a newly deployed version of the react client
make requests to old java back-ends, because haproxy simply routes api traffic to any available java backend.

As i understand haproxy seems to have support for sticky-backends based on some rules, but this defeats the purpose of having a cluster of backends for load-balancing.

How do others tackle this problem?

**Tags:** kubernetes, continuous-deployment


---

## 1 answers

### Answer by username_1 on 2020-07-16. Score: 2 | Accepted answer

Modern way to achieve seamless roll-out in this scenario is not on the load balancing (i.e. haproxy) side, but instead via proper deployment planning, backward compatibility and/or feature flags.

The issue with load-balancer tinkering is that in the end of day even if you get sticky sessions right it's not going to solve your problem. The reason for that - imagine a user that opened your app in a browser with old react. Underneath, you deploy new java back-end. If the user doesn't reload her browser - she's still going to use old react app with new back-end no matter what (just because javascript is already loaded to the browser).

Instead, look at following example how you can achieve it using API versioning:

* Let's assume that data model on one of your api end-points is going to change
* Let's say your old api was /v1 (or even un-versioned)

Here is how you can solve it:

1. You create /v2 version of your api, register /v2 version in your react app
2. Your latest java back-end needs to still have both /v1 and /v2
3. You first deploy all java back-ends to your back-end deployment with /v2 support (all your UI is still /v1 - but this is fine, because latest back-end supports it)
4. Once all back-ends are deployed, you can start roll-out of your UI deployment with latest image (again, experience is seamless since all back-ends support both /v1 and /v2)

As you can see, in the above approach, version conflict is avoided and experience is seamless.

P.s. You might want to consider splitting your docker image in 2 - it's a little odd to have a multi-purpose image with 2 entrypoints. There may be little justification for this design.

> **Comments:**
> **username_2**: I agree with @toledor. The usual use case when it comes to microservices is that you keep your deployable as minimal in size as possible with many instances as needed. This is something that K8S handles very well and is suited for the purpose. Best practice is to have 1 deployment for each service. That way you can control your entrypoint better too.  

---

