Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setup joyent instances for each team #69

Open
gerad opened this issue Oct 20, 2013 · 5 comments
Open

setup joyent instances for each team #69

gerad opened this issue Oct 20, 2013 · 5 comments
Assignees

Comments

@gerad
Copy link

gerad commented Oct 20, 2013

ping gerad for the joyent api keys

for each team:

  • create a joyent instance
  • set up dns for each joyent ip (see: dns setup #71)
  • generate a ssh keypair for the team
  • add the private key to the database
  • add the public key to the joyent instance and the github repo (so ssh agent forwarding works)
  • add the node knockout public key to the joyent instance
  • display the private key on the team page to logged in users
  • show instructions for team members on how to add the private key to their .ssh directory (and enable ssh agent forwarding) on the team page and also in the github repo readme (via https://github.com/nko4/website/blob/master/scripts/create-repo.sh)
@ghost ghost assigned gerad Oct 22, 2013
@gerad
Copy link
Author

gerad commented Oct 30, 2013

@tjfontaine here are the highlights for the joyent deployment code:

We are planning on setting up one team at a time sequentially. Depending on your guidance, we may parallelize (by manually running the setup script in multiple windows). We would never try and set up more than 10 teams a time in parallel.

This is the code that sets up a single team: setup-team.coffee. It:

  1. instantiates a new joyent instance
  2. sets up dns for it
  3. adds the teams public keys from github to the authorized_keys for the root user
  4. generates a deploy key on the box and uploads that to github
  5. and finally configures the box for the competition (by installing node, creating a deploy user, and enabling process monitoring with runit)

I'd appreciate a review of all the code linked to in the steps above, as well as a high-level sanity check of whether anything I'm doing seems crazy. In particular, some questions that you might have opinions on:

  1. instead of running step5 over and over again, perhaps it makes sense to create an image and just initialize the box with that?
  2. adding people's github public keys to authorized keys is magical (you get login to your box without specifying anything, but is it crazy)?
  3. maybe it makes sense to do a two step process:
    1. get everybody set up, but without ssh access to their box, and with readonly github access; and then
    2. give people ssh and github access

The process will error out sanely, but I haven't yet done anything to support gracefully restarting if there are errors. I'm going to work on that today.

@tjfontaine
Copy link

I looked over the code, this all seems pretty straight-forward to me, hopefully there aren't [m]any errors. By erroring out sanely do you mean you have some sort of cleanup script that potentially goes through and cleans up what might be leftover in joyent, github, and linode after an error?

I wanted to have a story for you on step5 with the image management that's rolling out, but I don't think it will be deployed in time for NKO to make use of it when provisioning team instances, or even if it is I doubt you'll want to change at the last min.

As much as I'm not a fan of automagic addition of ssh keys (let alone passwordless keys in general) for this style of competition and the potential level of aptitude of your contestants it seems pertinent.

What do you want to achieve with readonly access to github and no ssh access?

I would advocate getting the instances as close to what you'll be delivering and then snapshotting them, such that you have a pristine state to rollback to for a contestant that happens to completely screw up their environment you don't have to worry about a re-provision.

@gerad
Copy link
Author

gerad commented Oct 30, 2013

Awesome. Thanks TJ. Read-only would be just to have fewer moving parts the last couple days (so instead of slowly provisioning teams on the last two days, we quickly just add ssh keys). That being said, maybe it's ok if people want to get in and muck around a bit early.

@gerad
Copy link
Author

gerad commented Oct 31, 2013

Actually two additional questions for you @tjfontaine

  1. what data center should I instantiate these machines in?
  2. i'm currently using this package: ec521e7a-8799-4ffc-a914-bb41233f25f5 which is the 512Mb KVM package. Is this the correct one? I just noticed that it only has 500Mb of disk, so I just wanted to confirm.

@tjfontaine
Copy link

You'll want to do this in us-east and it should have 16gb of disk, have you looked at the space available in /data?

gerad pushed a commit that referenced this issue Nov 2, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants