In this section, you will setup your local development environment. You can do this in various ways including running it locally on your computer, configuring Vagrant or Docker, using Amazon Workspaces. In this lesson, we show how you’ll do this using an EC2 instance that you will SSH into.
Launch a Ruby Development Environment on EC2
- Create an EC2 Key Pair and save it to a secure location
- Launch this CloudFormation stack and enter the required parameters
- SSH into the Ubuntu EC2 instance Then, run the commands listed below:
git clone https://github.com/stelligent/honolulu_answers.git
git clone https://github.com/stelligent/honolulu_jenkins_cookbooks.git
NOTE: When executing
bundle install above, you might get an error like “Your Ruby is 1.9.3 and your Gemfile indicates 2.0”. To fix this error, edit your
Gemfile. (Thank you to Esteban Fallas for for this explanation).
Setup your GitHub Account
- If you don’t have a Github, create a free one here: https://github.com/signup/.
- Login to your account by going to https://github.com/login
- Go to https://github.com/codeforamerica/honolulu_answers
- Click the Fork button. A message will display “Where do you want to fork this to?”. Click on the button that says Fork to YOURUSERID.
- Create an SSH keypair by SSHing to the AWS CLI instance you created when launching the CloudFormation stack in the section above. In the example below, you will use the email address that’s registered with your GitHub account. You can find yours by going to https://github.com/settings/profile/. Accept the defaults after running this command below. NOTE: Use the email address linked with your Github username. For example, firstname.lastname@example.org.
[sourcecode]ssh-keygen -t rsa -C email@example.com[/sourcecode]
After logging into your GitHub account, go to your GitHub SSH Keys settings at https://github.com/settings/ssh/. Click on the Add SSH Key button, give it a name and paste the contents of the public key into the Key text field. Then, click the Add key button. Enter your GitHub password when prompted.
Commit changes to Github
From the root directory of your EC2 instance change directory to sample_app.
Open the home.html.erb file
[sourcecode]sudo vim home.html.erb[/sourcecode]
Make a modification to the contents of the file and save it. Change directory to honolulu_answers.
Add the file in Git
[sourcecode]git add .[/sourcecode]
Commit the file to Git
[sourcecode]git commit -m "Modify the application code"[/sourcecode]
Push it to the Git master.
Creating a new repository based on an existing repo
Why would I want to do this? The purpose of doing the following is if it is desired to use a public or private Git repository for a completely independent project. There will be no contributions back to the original project. For instance, creating a Cloud Deployment Pipeline for an open-source application.
- Access to a local VM or Linux machine command line with internet access (commands are based on Ubuntu)
- A GitHub account
- GitHub installed . For Ubuntu: (see http://git-scm.com/download/linux for other versions)
apt-get install git
- Knowledge of Linux command line navigation and directory / copy operations (Ubuntu basic guide https://help.ubuntu.com/community/UsingTheTerminal)
- In the GitHub WebUI (https://github.com/), create a new repository and name it accordingly (new_repo for this document)
- Clone the repository that will be used as the base for the new repository (base_repo for this document). (Note: this URL is listed in the GitHub WebUI):
git clone https://github.com/org_or_username/base_repo.git
- On the local machine there should now be a new directory with that repository contents within it; user will still be in home directory (there will be some output of the command saying whether clone was successful)
- In the same fashion, clone the new repository that you created in the first step with that repository’s unique URL (make sure you are in your home directory and not in the base_repo directory that was just created)
- Now, there will be two repository directories on your local file system, new-repo and base_repo
- Change directories to base_repo and delete .git (a directory) and .gitignore (a file)
- .gitignore may or may not exist but a .git directory certainly will exist and will be hidden (ls -a will show it)
- The reason for doing this is that .git holds all repository information that tracks the repository and identifies as a .git repository and .gitignore contains any files or directories that should not be tracked in the repository
- Once both of those directories are deleted, copy all of the content from base_repo to new_repo
- This accomplishes getting all relevant files from the base_repo to the new_repo without a git repository being associated with the content
- Now, change directories to the root directory of base_repo
- Validate that all of the files copied over correctly
- Next, the base_repo needs to be reinitialized to ensure that the Git repository is initialized correctly
- Run the command:
- A message should confirm that the git repository was initialized or reinitialized
- Additional commands need to be run to add, commit, and push the changes to the GitHub repository (online)
- git status (optional, will show all the files that have been added as untracked)
- git add . – This command adds all the untracked files that were copied to the repository
- git status (optional, now this should show no untracked files, but all new files added to the repository)
- git commit -m “first commit” – Adds commit message to all the new files in the repository
- git push -u origin master – pushes the repository to GitHub
- Browse to the GitHub repository on GitHub and all of the files / directories should appear with the message “First Commit”
Now a completely separate repository exists that can be used independently of the repository it is based on.
Deleting provisioned AWS resources
Go to the CloudFormation console and delete the corresponding CloudFormation stacks.
Directory Structure and Naming
At Stelligent, we follow a standard repository structure for reliability, familiarity, and logical structure of components across projects. Typically Cloud Deployment Production Line implementations consists of three repositories:
- Application Repository – This will be whatever the name of the application repository is. For example,
- Cookbook Repository – Typically, we name this the name of the application repository followed by cookbooks. For example,
- Jenkins Configuration and Deployment Repository – Typically, we name this an abbreviated name of the application repository followed by jenkins_cookbooks. For example,
The application repository contains all application configuration and deployment information and is typically structured as follows:
- README.md (file)
The Cookbook Repository contains all application specific deployment Cookbooks:
- Cookbook X
- Cookbook Y
- Cookbook Z
- Files: Readme.md
- Example: https://github.com/stelligent/honolulu_answers_cookbooks
Jenkins Configuration and Deployment Repository
The Jenkins configuration and deployment repository contains all Jenkins-specific deployment cookbooks, scripts, and CloudFormation templates:
- Cookbook X
- Cookbook Y
- Cookbook Z
- vpc.cfn.template (called by deployment script)
- jenkins.cfn.template (called by deployment script)
- Example: https://github.com/stelligent/honolulu_jenkins_cookbooks