Hi, I was thinking about the blue/green and canary with Argo rollouts and they are an effective way to test being able to quickly rollback in case of issue. But what happens if one wants to just test online but exclusively in a private way? That would be a staging environment. An option could be to just have a secondary domain and deploy the website in that secondary domain temporarily and perhaps with a modified react component or any equivalent layer only giving access to one staging user? How do big companies make that staging environment to be possible to be online but without having it exposed to public in production? In data analytics applications it's easier because usually all is in an intranet but what happens with webs that are usually B2C applications?.
You can automate this with experiments. You basically use metrics to check the success of the rollout and based on those metrics, approve or roll back.
I was wondering if an alternative to using Argo rollouts would be to use Istio. It would add more complexity to the deployment in general but Istio already has the implementation for blue/green and canary that kubernetes basic networking lacks.
Argo Rollouts works together with Istio and other service meshes to manipulate the traffic as needed. Although you could use Istio on its own and configure it all yourself, using it in combination with Argo Rollouts or Flagger is easier.
Hi@@GeertBaeke , I thought if one is using Argo rollouts or Flagger, and then one had it configure it with Istio, the blue/green and canary features of Istio are not needed any more, one is only going to use the service mesh part (and others) of Istio.
@@davidpratrThat was indeed what I was pointing at. Flagger and Rollouts using the service mesh features to orchestrate the canary or blue/green deployment. I must admit that I do not use Istio that often and tend to use Linkerd. So I am not that familiar with Istio's standalone features. With Linkerd, you have to use it with Rollouts or Flagger because it has no such standalone functions. Last time I checked 🙂
@@GeertBaeke I see Flagger is more related to Flux. Well, I think it's clear that if one starts a project from scratch and one knows one will use ArgoCD, Argo rollouts is the way to go. Another thing would be if the project was already started with it's Blue/Green or canary with Istio, then it could be more challenging to adapt the whole thing to make the rollouts with both things Argo rollouts and the Istio rollouts capability.
Hi, I was thinking about the blue/green and canary with Argo rollouts and they are an effective way to test being able to quickly rollback in case of issue. But what happens if one wants to just test online but exclusively in a private way? That would be a staging environment. An option could be to just have a secondary domain and deploy the website in that secondary domain temporarily and perhaps with a modified react component or any equivalent layer only giving access to one staging user? How do big companies make that staging environment to be possible to be online but without having it exposed to public in production? In data analytics applications it's easier because usually all is in an intranet but what happens with webs that are usually B2C applications?.
Great video!
Great work !! Just wanted to know How to automate this?
You can automate this with experiments. You basically use metrics to check the success of the rollout and based on those metrics, approve or roll back.
I was wondering if an alternative to using Argo rollouts would be to use Istio. It would add more complexity to the deployment in general but Istio already has the implementation for blue/green and canary that kubernetes basic networking lacks.
Argo Rollouts works together with Istio and other service meshes to manipulate the traffic as needed. Although you could use Istio on its own and configure it all yourself, using it in combination with Argo Rollouts or Flagger is easier.
Hi@@GeertBaeke , I thought if one is using Argo rollouts or Flagger, and then one had it configure it with Istio, the blue/green and canary features of Istio are not needed any more, one is only going to use the service mesh part (and others) of Istio.
@@davidpratrThat was indeed what I was pointing at. Flagger and Rollouts using the service mesh features to orchestrate the canary or blue/green deployment. I must admit that I do not use Istio that often and tend to use Linkerd. So I am not that familiar with Istio's standalone features. With Linkerd, you have to use it with Rollouts or Flagger because it has no such standalone functions. Last time I checked 🙂
@@GeertBaeke I see Flagger is more related to Flux. Well, I think it's clear that if one starts a project from scratch and one knows one will use ArgoCD, Argo rollouts is the way to go. Another thing would be if the project was already started with it's Blue/Green or canary with Istio, then it could be more challenging to adapt the whole thing to make the rollouts with both things Argo rollouts and the Istio rollouts capability.