<div dir="ltr"><div>Olivier,</div><div><br></div><div>I have had a look through the IEP and here some of my comments</div><div><br></div><div><b>URL</b></div><div><a href="http://jenkins.io">jenkins.io</a> vs. <a href="http://www.jenkins.io">www.jenkins.io</a> - not a big deal (as <a href="http://jenkins.io">jenkins.io</a> doesn't have cookies at present) - but having your website on the no-www means cookies on the apex will propagate across all sub-domains.</div><div><br></div><div><b>DNS</b></div><div>Not mentioned - but since you can't have an apex (<a href="http://jenkins.io">jenkins.io</a>) pointing at a CNAME, then covering off how that is handled by Azure would be useful for non-Azure people. You may need to migrate DNS to handle this "the Azure way" - an additional consideration.</div><div><br></div><div><b>Container Architecture / Content Location</b></div><div>Baking the content inside a docker container raises many pain points, so keeping content on AFS/blob store makes sense.</div><div><b><br></b></div><div><b>Storage</b></div><div>I had a quick look at IEP-006 - it didn't mention Azure File Storage (AFS) being the storage system being considered.<div><br></div><div>My only concern would be that AFS may not be able handle the high I/O (small files, lots of them) effectively - compared with local SSD storage. We had issues when testing the Amazon equivalent (EFS) - where the characteristics of EFS need to be well understood to make it perform properly.</div></div><div><i>However - given <a href="http://jenkins.io">jenkins.io</a> is static - an aggressive CDN will eliminate nearly all IO at the web-servers except after cache invalidation.</i></div><div><br></div><div>Given that <a href="http://jenkins.io">jenkins.io</a> is on a 30 minute refresh cycle, some of the advantages of AFS would be that it means you don't need to redeploy the content.</div><div><br></div><div><b>CDN</b></div><div>I would strongly recommend using a CDN - it's the perfect use-case.  The only issue is cache invalidation (one of the 3 hardest things in computer science) - if a CDN is used then I think updating the IEP with the high-level CDN approach would be useful.</div><div><br></div><div><b>Success Criteria</b></div><div>I think having some success criteria would be useful - "Updates are published and cache invalidated with 30 minutes", "Response time of X", "Cluster handles failures and recovery without operator intervention" etc.</div><div><br></div><div><b>Blob Storage + CDN vs Container + "File Store"</b></div><div>(you need to keep existing URL structure - changing URLs for this project is a non-starter)</div><div><br></div><div>Biggest loss with blob store + CDN is that your development cycle is quite different to container + file-store. We've found this change in development cycle makes rapid development a lot slower / or you end up with a container version anyway (and it's subtly different - which introduces deployment 'weirdness')</div><div><br></div><div>The other advantage of "container on k8s architecture" is that it then looks like every other application - big win for maintenance / documentation at Ops level.</div><div><br></div><div><b>HTTP => HTTPS</b></div><div><br></div><div>I would suggest that HSTS headers are added to the HTTPS site. Initially with a short expiry. </div><div><br></div><div><b>Load Balancer</b></div><div><b><br></b></div><div>It's unclear from IEP-004 / IEP-006 how a request is routed in from the internet (or CDN) to a particular container.</div><div><b><br></b></div><div><b>Load Testing</b></div><div><div><br></div><div>Load test the solution to determine how long it takes to "update" after cache invalidation and that the server can respond to quickly under heavy load during cache invalidation.</div></div><div><br></div><div>Get some real-world stats from <a href="http://jenkins.io">jenkins.io</a> - especially around events like Jenkins World etc.</div><div><br></div><div><b>Development</b></div><div>Ensure that there is a streamlined development environment for rapid prototyping of content for non-k8s savvy users (e.g. people who just want to do "docker-compose up" and start editing pages)<br></div><div><br></div><div><br></div><div><b>Overall Comment</b></div><div>I think your proposal is sound - my preference (if implementing / supporting) would be for a solution like:</div><div><b><br></b></div><div>Aggressive CDN => Azure load balancer => cluster load balancer[3] => cluster of k8s servers[2] => Docker containers[1] => Azure File Storage backend</div><div> </div><div>[1] Docker containers would be relatively static and just serve up content</div><div>[2] I only quickly read through IEP-004 (k8s) so I'm not sure on the details of what you're doing here (for web load balancing etc) - but we have iterated through this at CloudBees on the AWS ECS platform (much the same). </div><div>[3] I'm a bit hazy on how the cluster level load balancing works vs. Azure load balancer - we went through many iterations of this on AWS ECS to get a robust routing solution (note: AWS ALBs cat do a lot more heavy lifting (routing) now than when we started out)</div><div><br></div><div><b><br></b></div><div><br></div><div>Cheers,</div><div><br></div><div>Ben</div><div><b><br></b></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 July 2017 at 23:05, Olblak <span dir="ltr"><<a href="mailto:me@olblak.com" target="_blank">me@olblak.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>Hi,<br>
      <br>
      I am planning to migrate <a href="http://jenkins.io" target="_blank">jenkins.io</a> on Azure.<br>
      I wrote an <a href="https://github.com/jenkins-infra/iep/pull/10" target="_blank">IEP</a> document about it and I would be
      interested by any feedback or concerns<br>
    </p>
    <p> To make a long story short, I plan to mount Azure File Storage
      into several docker containers and deploy them on the k8s cluster.</p>
    <p><br>
    </p>
    <p><br>
    </p>
  </div>

<br>______________________________<wbr>_________________<br>
Jenkins-infra mailing list<br>
<a href="mailto:Jenkins-infra@lists.jenkins-ci.org">Jenkins-infra@lists.jenkins-<wbr>ci.org</a><br>
<a href="http://lists.jenkins-ci.org/mailman/listinfo/jenkins-infra" rel="noreferrer" target="_blank">http://lists.jenkins-ci.org/<wbr>mailman/listinfo/jenkins-infra</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">















<table style="width:570px;font-family:verdana,arial,sans-serif;line-height:1.2em"><tbody><tr><td><div style="font-weight:bolder">Ben Walding</div><div><a href="mailto:bwalding@cloudbees.com" target="_blank">bwalding@cloudbees.com</a></div><div>Operations Manager</div><div> </div><div><b>CloudBees, Inc.</b></div><div><a href="https://www.cloudbees.com/" target="_blank">www.cloudbees.com</a></div></td><td style="text-align:right"><a href="https://www.cloudbees.com/" target="_blank"><img src="https://docs.google.com/a/cloudbees.com/uc?id=0B_9xfR5V4hiJa1d6NUxnZmxwZlE&export=download" width="200" height="56"></a><br><i style="font-size:17.6px;font-family:Futura,Futura-Medium,"Futura Medium","Century Gothic",CenturyGothic,"Apple Gothic",AppleGothic,"URW Gothic L","Avant Garde",sans-serif">software at the speed of ideas</i></td></tr></tbody></table><table style="width:570px;font-family:verdana,arial,sans-serif;line-height:1.2em"></table></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>