Forum Discussion
NotVeryCreative
Nimbostratus
NimbostratusPossible 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...
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.
Paulius
MVP
MVPNotVeryCreative 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.
NotVeryCreativePaulius 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
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?
- NotVeryCreative
Paulius Currently, the listening ports are configured based on which version/instance is being deployed.
Any process port: {env}{app}{usage}{instance}
- in this case the env is production (9) and the instance port (0/1) will change based on the version.