Forum Discussion

NotVeryCreative's avatar
NotVeryCreative
Icon for Nimbostratus rankNimbostratus
Feb 09, 2023
Solved

Possible to isolate Application Releases within the BIGIP

Our company has monthly application releases (many application and web servers).  All of this is QA'd together on a staging environment.  The next step is to deploy to production the new version, but the old version is still running (in/activate members of pools when everything is up).

Sometimes it's okay for the old version to communicate with the new version, but I'm looking for a way to ensure that the old version only communicates with the old version.   Likewise, the new version should only communicate with the new version.

Big Picture, we would like no production downtime and both version to be active (existing and new users)
What is a reasonable approach for handling this? (route domain, vlan, irule, dns, etc.)   Or maybe it's just a bad idea.

We could have the the application developers create a location service (find address of process to talk to), but I was hoping to take advantage of our company's monthly bundled release cycle.

TIA!

application delivery
  • Paulius's avatar
    Paulius
    Feb 09, 2023

    NotVeryCreative If that is the case all you would have to do is configure a new pool with pool members listening on this new port. In the iRule you could search for a specific host header to go between the current version and previous version.

5 Replies

Sort By
  • Paulius's avatar
    Paulius
    Icon for MVP rankMVP
    Feb 09, 2023

    NotVeryCreative If you have 1 BIG-IP or and HA pair of them that covers both staging and prod you can either split this up by different virtual servers or you can have them on the same virtual server and use different FQDNs for QA and Prod and split that up using an iRule to direct it to different pools depending on the HTTP header host field. If you split this up by virtual servers you wouldn't have to do anything other than connect to the appropriate virtual server for the environment that you would like to test.

    • NotVeryCreative's avatar
      NotVeryCreative
      Icon for Nimbostratus rankNimbostratus
      Feb 09, 2023

      Paulius I was probably not very clear in the above post.   QA and Production are separate FQDNs and are being managed as you described.  For QA, we can take it down and then bring up the new code base.

      For production releases, it would be nice to have two instances of production running (the old version and the new version).  The old version should only communicate with the previous deployment, while the new version should only talk to the new deployment.

      How would one design a plan with no downtime for production releases (assume databases are backwardly compatible)  where: 

      • Existing users would stay on old version (only talk to each other)
      • New user would use the new code base (only talk to each other)
      • Paulius's avatar
        Paulius
        Icon for MVP rankMVP
        Feb 09, 2023

        NotVeryCreative I suppose this depends on application and protocol but typically if you deploy a release for lets say an HTTP/S website you wouldn't have both old version and new version running in parallel to each other because that is what QA is for. It seems like what you should really have is a Dev, QA, and Prod setup but I have never seen two versions of an application running in parallel within the same environment other than what I have described. How would you go about having two different application versions running simultaniously on the same prod device?