*. (CNAME record to for running webservers with name-based vhosts)īoth EC2 instances are running Debian Jessie at this point, but you can obviously choose whatever Linux distribution you like.Devbox: the actual workstation, sized according to what I need, running in the private subnet, and only accessible from the VPN/Bastion instance.VPN/Bastion instance: a small instance that acts as an SSH bastion (I might add an OpenVPN server later) in the public subnet.Internal DNS zone (using Route53): cloud.int.a NAT gateway in the public subnet (so nodes in the private subnet can access the internet).a public subnet (10.1.11.0/24, instances will also get a public IP).Yesterday, I built my initial cloud-based workstation setup, on AWS. Generally speaking: if you don’t own the physical disk, always encrypt whatever you store on it. Some cloud providers are rather lazy when it comes to scrubbing used storage, in which case you can find/recover some interesting stuff when running data recovery or forensics tools on a fresh cloud instance. But we still don’t want to mess with firewalls too much, right? Well, in that case we need to make sure that our cloud-based workstation runs on a secure, trusted network that only we can access.Īnother thing is disk encryption. But doing a quick network scan at a conference, at an airport, or at your local coffee place quickly proves why we would be very, very stupid if we were just going to get a VM and tie it to the public internet. And that’s mostly fine on a secure, trusted network. No annoying firewalls in between, and no sysadmin telling you what you can or cannot do. Spin up virtual machines, containers, or app servers, bind ports on your laptop and access your stuff through the browser. One of the big benefits of local development is that you can basically do whatever you like. If you spend 99% of your time in either a browser or a terminal, this setup can definitely work for you. If you spend most of your time in a graphical IDE, this setup is probably not for you. But a another limitation, at least with my setup, is that you’re limited to using text-based tools. The obvious primary limitation of a cloud-based workstation is that you need to have an internet connection to use it. Or leaving my MacBook Pro at my desk and taking my iPad into a meeting and still do some coding if I have to. I also like the idea of being able to switch my 15" MacBook Pro for something smaller when I’m commuting by bike. I don’t technically need this, but I do like the idea of being able to fly abroad with a small MacBook that has nothing on it other than iTerm2 and Chrome. Or you’re a cyclist, and want to have an option to pack light instead of riding to the office with a 15" MacBook Pro strapped to your back. Or maybe you fly often and a 15" MacBook Pro is just inconvenient, or you don’t want airport security to pry into your precious source code. Or you have multiple clients and their code cannot be on the same machine (and you don’t want to buy yet another MacBook Pro). But maybe you’re a consultant and your client has a policy that doesn’t allow you to have their code on your machine. And I’m certainly not going to debate the benefits of having a powerful machine. Yet, in the past few weeks I’ve started to explore options for having a cloud-based workstation. I’m lucky enough to own a top-of-the-line 15" MacBook Pro which has more than enough horsepower for whatever I need to do, and even my ‘old’ machine, a 2014 15" MacBook Pro, would still be perfectly good for whatever I need to do. This blog explains why you might want to, what to consider, and how to do it securely. DIY Cloud-based workstation ←Home About Subscribe DIY Cloud-based workstation Running your local development workloads in the cloud.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |