30:T498,md`## To the cloud We want similar functionality in the cloud (AWS). Unlike on premise, we have full control of the hardware (including hosts and networking). Great power but also great responsability. More flexibility but more sysadmin work. One of the reasons I picked *docker* when building the on premise infrastructure is to have control on the host environment running the services. We didn't want changes in the host OS to affect our code. That is not a problem since we control the OSes we install in the hosts. In the cloud, with the current setup we first capture the infrastructure we want in code and then we have services that we deploy as necessary. A new service is a new repo that exposes a new [systemd service](https://wiki.debian.org/systemd/Services). There is a nice benefit with this approach: deployments are going to be blazing fast because we don't have to build docker images. We just need to transfer code and restart a service. As of right now, the deployment process is manual because I wanted to be able to troubleshoot the different processes, specifically *ssl* traffic between the *webserver* and the load balancer and the *SAML flow*. `31:Ta03,md` ## High level view of the solution

${note( `Visualization of this [CF template](https://github.com/drio/aws-drio-stack/blob/main/templates/main.yml).` )} I wrote a pipeline using *aws-cli* and *cloud formation (CF)* that instantiates the AWS resources we need for our infrastructure. CF allows you to capture in code your infrastructure. - **EC2** (2 instances, each on different AZs). - Load Balancer (**ELB**) - requires **VPC** setup (two subnets) - each subnet in different AZs. - We also need an internet gateway that routes traffic to and from the Internet - **Route 53** to register new domains - **Certificate Manager** to create TLS certificates - It connects the certificate to the domain very easily There are other AWS services that I explored but I ended up not using: [codedeploy](https://aws.amazon.com/codedeploy/) and [Auto scaling groups](https://aws.amazon.com/autoscaling/). I didn't incorporate codedeploy because I prefer our custom solutions based on open source. Codedeploy also adds extra complexity that would have delayed coming out with an MVP. Autoscaling may be good in the future but it also adds extra complexity. Right now, the configuration of the ec2 instances is very minimal. It only has the things it needs to talk to cloud formation. Once the stack is up and running I: - *rsync* some code ([golang server](https://github.com/drio/aws-drio-stack/blob/main/src/server.go)) to the machines - Run [the server](https://github.com/drio/aws-drio-stack/blob/main/src/server.go) that talks to the *IDP server* and serves endpoints and assets. Some endpoints are authenticated via *SAML*. That process is manual for now. Like I mentioned before, this helps me in the process of troubleshooting the different interactions between the EC2 instances and the other components (load balancer and IDP). When you create your stack (CF) from the very first time, there are a few things you have to do manually: - Buy the domain - Generate metadata - Upload metadata to IDP - Generate the self-signed SSL certs to talk https between the load-balancer and the webserver Then, it is a matter of pushing code updates to the different machines. There are two set of certs here: - One that we use for the server (service provider) to talk against the IDP. - Another one for the server to talk HTTPs. Once I am happy with it, the deployment step will be automatic after the infrastructure is up and running (cloud formations is done). `32:T46c,md`## Next steps - Stop listening on port 80 (only 443) - ✅ Dedicated filesystem location for each service. - ✅ Automate deployments/write the deployment pipeline (pushing code changes to the boxes) - ✅ Modify CF template to add proper role so we can ssh using SSM (AWS system manager) - Change VPC CIDRs so we reduce the network space. - implement SAML logout - tests adding/removing ec2 instances. - Be able to see costs associated with our infrastructure (no permissions right now) - NATting the ec2 instances so they cannot be rechable over the Internet. Right now they only have 22, 80 and 443 ports open but packets will still reach the kernel. - I am using a golang server to talk https and SAML. It will also have to redirect traffic to other processes (probably running in other languages - python) that server specific endpoints. - Metrics, metrics, metrics. - How do we store the SSL certs? Right now we are pushing them to a private repo. - Write the SMS app in this environment? - Something a bit more creative that touches other aspects of the cloud (wifi dataset)? `33:[{"id":"35cc7bdd13e1e0cf519542bf420a0cc25393b0bae56800998708f7140db9624a14394bd818e88d4162f111d70f8826b98a1d60af738fe35e4b379272ef0a367a","href":"https://static.observableusercontent.com/files/35cc7bdd13e1e0cf519542bf420a0cc25393b0bae56800998708f7140db9624a14394bd818e88d4162f111d70f8826b98a1d60af738fe35e4b379272ef0a367a","name":"cf-designer.png","type":"image/png","lastModified":1647111665153.745,"size":306907},{"id":"88f46c6b841198c14da1df4a46bca2266f329f44118e94d53e5a265a8e20b3feecf9fe0bff136c3b86342392f000ac6ef40faa2cf49b49b26046d21a5bf13f5f","href":"https://static.observableusercontent.com/files/88f46c6b841198c14da1df4a46bca2266f329f44118e94d53e5a265a8e20b3feecf9fe0bff136c3b86342392f000ac6ef40faa2cf49b49b26046d21a5bf13f5f","name":"three-amigos@1.png","type":"image/png","lastModified":1647120175262.536,"size":161764}] 2e:{"title":"aws migration notes","cells":[{"id":421,"value":"md`# aws migration notes`","pinned":false,"hidden":false,"mode":"ojs"},{"id":345,"value":"writeSentence(\"AWS migration notes\", {\n xRand: 5,\n yRand: 5,\n stroke: \"steelblue\",\n strokeWidth: 0.8,\n repeat: 11\n})","pinned":false,"hidden":false,"mode":"ojs"},{"id":83,"value":"md`![](https://imgs.xkcd.com/comics/the_cloud.png)`","pinned":false,"hidden":false,"mode":"ojs"},{"id":61,"value":"md`## On premise\n\nWe like our current infrastructure.\n\nThe sysadmins gave us four Linux machines (two environments) and we setup *docker* and wrote a pipeline to build and deploy containers that provide services. \n\nDeploying is a simple as running a *makefile* target from the host machine. \n\nTo add new functionality you create new containers running the services you need. There is a proxy/webserver that maps urls to a ports in a container. All the paths require *SAML* authentication and the endpoints have access to users info in the html session.`","pinned":false,"hidden":false,"mode":"ojs"},{"id":67,"value":"$30","pinned":false,"hidden":false,"mode":"ojs"},{"id":71,"value":"$31","pinned":false,"hidden":false,"mode":"ojs"},{"id":305,"value":"md`${note(\n `\n

\n \nThe Golang server is what talks *https* and *SAML*. [Samltest](https://samltest.id/) helps you with the *SAML flow* by implementing a *SAML IDP*.\n \n`,\n 0\n)}`","pinned":false,"hidden":false,"mode":"ojs"},{"id":25,"value":"md`\n## Toughts and comments\n\n**Cloud formation** is what I am using for now because the abstraction level provided by the *cdk* is too much and will make it difficult to troubleshoot and understanding the system. The CDK may be fine in the future since it generates templates. CF Templates are a good way to get your head around how AWS works. \n\n**Debugging** CF infrastructure can be hard. Maybe it is because my lack of experience. \n\n**Lambdas** seem like a great thing but I don't think it makes sense to use them to build APIs, specially complex ones. I don't think they should replace a general purpose application host. You'd have to make changes in your applications' code and debugging is not trivial. I think they are more suitable for small snippets of code that don't change often.\n\n**Vendor lock-in is real. Remain vigilant.** We already have solutions in our traditional infrastructure that work well. We want to adapt them for the cloud.\n\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":269,"value":"md`### Some random notes:\n\nI find it troubling seeing all the resources from other IAM users? Is it possible to fix that?\n\nI think it'd be beneficial to go into interactions with AWS people having had tried to build things on our own. The certifications are fine but do not give you that much practical experience.\n\nWhy don't we have a system like [SAMLtest.id](https://samltest.id/) where you can upload your metadata without the need of open a ticket or send an email?\n\nAt some point we are going to need to access on-premise resources.\n\nI built this trying to avoid interacting with the sysadmins but when we are ready we are going to have to interact with them for:\n\n- attaching our metadata\n- add dns entries \n- generate certificates\n\nMaybe dns interactions are not necessary if can use our own domains. Is that possible?`","pinned":false,"hidden":false,"mode":"ojs"},{"id":74,"value":"$32","pinned":false,"hidden":false,"mode":"ojs"},{"id":141,"value":"html`\n

Demo

\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":392,"value":"md`\nIn this demo we are going to:\n\n- Start our cloud formation statck\n- rsync code into the ec2 instances\n- start the golang server in both instances\n- Hit an endpoint that is authenticated to see the SAML flow in action\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":402,"value":"md`## References\n\n1. Gihub [repo](https://github.com/drio/aws-drio-stack)\n2. [SSH against ec2 instances via SSM](https://blog.ruanbekker.com/blog/2021/03/10/ssh-using-aws-ssm-session-manager/)\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":12,"value":"import { slide, slide_style } from \"@mbostock/slide\"","pinned":false,"hidden":false,"mode":"ojs"},{"id":16,"value":"slide_style","pinned":false,"hidden":false,"mode":"ojs"},{"id":287,"value":"function note(content, padding = \"20\") {\n return md`\n

\n${content}\n

`;\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":341,"value":"import { writeSentence } from \"@bartok32/handwriting-text-generator\"","pinned":false,"hidden":false,"mode":"ojs"}],"files":"$W33","stdlib":"1","titling":"auto"}