Added AWS guide

[gibbster]

Created a guide for AWS

[tomerd]

please remove .DS_Store

[weissi]

[retarged to main branch]

[tomerd]

hi @gibbster do you want to bring this over the finish line?

[gibbster]

hi @gibbster do you want to bring this over the finish line?

Absolutely. I'll pick this up next week.

[hassila]

@gibbster nice work, was planning to do this and found you already did. Do you plan to finish it up, or do you want help?

[gibbster]

Thanks @hassila - yes, I must admit I've been dragging my feet on this, so would love some tips. From where I stand I think I need to do two things:

1. review everything to make sure nothing has changed too much since I authored it. E.g. if there's any best practices that have shifted since I wrote the original version
2. figure out the current best way to deploy this without installing the toolchain.

If you have any thoughts on either of these topics I would appreciate the help!

[hassila]

@gibbster I will try to follow the guide and see if it still works and what feedback I can give - with regard to 2 above, I saw the discussion - maybe a good approach would be to separate concerns a bit and provide information on both

1. how to set up an AWS host for development (which is useful for those of us with unsuitable workstations for linux development) - this would include the toolchain and be the actual build environment used for building the app for deployment
2. how to set up an AWS host for deployment (using one of the strategies documented - without toolchain, but perhaps simplest with the tar/zip approach (personally I think it would be nice to not use docker for everything...).

For the first use case for development, I would consider adding something along these lines also:

---

In addition to the AWS console, there is also a command line interface for AWS that can be helpful for day-to-day development with a single instance.

It allows for setting up some simple useful shell commands (this example for the awesome fish shell for an Ubuntu instance) for an individual developer, e.g.:

amazon-dns // find public DNS name for a specific instance ID
amazon-start // start specific instance
amazon-stop // stop specific instance
amazon-login // log into specific instance

> functions amazon-dns
# Defined in /Users/xxx/.config/fish/functions/amazon-dns.fish @ line 1
function amazon-dns
 aws ec2 describe-instances --output text --instance-ids i-0d6f830050ccf632b --query 'Reservations[].Instances[].PublicDnsName' ;
end

> functions amazon-start
# Defined in /Users/xxx/.config/fish/functions/amazon-start.fish @ line 1
function amazon-start
 aws ec2 start-instances --instance i-0d6f830050ccf632b ;
end

> functions amazon-stop
# Defined in /Users/xxx/.config/fish/functions/amazon-stop.fish @ line 1
function amazon-stop
 aws ec2 stop-instances --instance i-0d6f830050ccf632b ;
end
> 

> functions amazon-login
# Defined in /Users/xxx/.config/fish/functions/amazon-login.fish @ line 1
function amazon-login
 ssh -i .ssh/xxx-home.pem ubuntu@(amazon-dns) ;
end

---

This gives on-demand command line access to the remote host (and one can always put amazon-stop in a cron job if desired...).

[gibbster]

@hassila - do you think building the binary with static-stdlib or static-executable would be preferable?

[fabianfett]

@gibbster -static-stdlib is definitely preferred over -static-executable.

[gibbster]

@hassila I added some updates. Let me know if it addresses the spirit of the static linking request, and if there's any best practices, technical details, screenshots, etc. I should add

[hassila]

Thanks @gibbster, super! I think the most important point is addressed now - the separation between a build host with toolchain and how to build with a static stdlib and deploying on a host without the toolchain. Basically it is the minimalistic approach of the tar archive outlined at (https://github.com/swift-server/guides/blob/main/docs/packaging.md) which points in the right direction.

Some minor structuring nits:

• Move aws.md to the new "docs" directory from the top level (the overall structure has changed since you forked, so you might want to update your fork first)
• Remove 'images/.DS_Store' as mentioned previously
• Add a link to https://github.com/swift-server/guides/blob/main/docs/deployment.md :-)

[gibbster]

@hassila - will do. One question: I see that the baseline branch is now main and not master. Should I create a new PR that is based off of main?

[hassila]

@gibbster super. I guess it doesn't matter from which of your forks branch the merge is done, but there was a baseline branch renaming some while ago AFAIU, so perhaps you want to update anyway (I usually fork the repo and do a local feature branch myself when contributing).

[gibbster]

Created a new PR with all the main branch commits merged in: https://github.com/swift-server/guides/pull/45