Tag: GitHub


Exploring ASP.NET Core Part 1: Deploying from GitHub

by Norm Johanson | on | in .NET | Permalink | Comments |  Share

ASP.NET Core, formally ASP.NET 5, is a platform that offers lots of possibilities for deploying .NET applications. This series of posts will explore options for deploying ASP.NET applications on AWS.

What Is ASP.NET Core?

ASP.NET Core is the new open-source, cross-platform, and modularized implementation of ASP.NET. It is currently under development, so expect future posts to cover updates and changes (for example, the new CLI).

Deploying from GitHub

The AWS CodeDeploy deployment service can be configured to trigger deployments from GitHub. Before ASP.NET Core, .NET applications had to be built before they were deployed. ASP.NET Core applications can be deployed and run from the source.

Sample Code and Setup Scripts

The code and setup scripts for this blog can be found in the aws-blog-net-exploring-aspnet-core repository in the part1 branch.

Setting Up AWS CodeDeploy

AWS CodeDeploy automates deployments to Amazon EC2 instances that you set up and configure as a deployment group. For more information, see the AWS CodeDeploy User Guide.

Although ASP.NET Core offers cross-platform support, in this post we are using instances running Microsoft Windows Server 2012 R2. The Windows EC2 instances must have IIS, .NET Core SDK and the Windows Server Hosting installed. The Windows Server Hosting, also called the ASP.NET Core Module, is required to enable IIS to communicate with the ASP.NET Core web server, Kestrel.

To set up the AWS CodeDeploy environment, you can run the .\EnvironmentSetup\EnvironmentSetup.ps1 PowerShell script in the GitHub repository. This script will create an AWS CloudFormation stack that will set up an EC2 instance and configure AWS CodeDeploy and IIS with the .NET Core SDK and Windows Server Hosting. It will then set up an AWS CodeDeploy application called ExploringAspNetCorePart1.

To avoid ongoing charges for AWS resources, after you are done with your testing, be sure to run the .\EnvironmentSetup\EnvironmentTearDown.ps1 PowerShell script.

GitHub and AWS CodeDeploy

You can use the AWS CodeDeploy console to connect your AWS CodeDeploy application to a GitHub repository. Then you can initiate deployments to the AWS CodeDeploy application by specifying the GitHub repository and commit ID. The AWS CodeDeploy team has written a blog post that describes how to configure the repository to automatically push a deployment to the AWS CodeDeploy application.

Deploying from Source

When you deploy from GitHub, the deployment bundle is a zip archive of the repository. In the root of the repository is an appspec.yml file that tells AWS CodeDeploy how to deploy our application. For our application, the appspec.yml is very simple:

version: 0.0
os: windows
files:
  - source: 
    destination: C:\ExploringAspNetCore
hooks:
  ApplicationStop:
    - location: .\RemoveApp.ps1
      timeout: 30
  ApplicationStart:
    - location: .\InstallApp.ps1
      timeout: 300

The file tells AWS CodeDeploy to extract the files from our repository to C:\ExploringAspNetCore and then run the PowerShell script, InstallApp.ps1, to start the application. The script has three parts. The first part restores all the dependencies for the application.

# Restore the nuget references
"C:Program Files\dotnet\dotnet.exe" restore

The second part packages the application for publishing.

# Publish application with all of its dependencies and runtime for IIS to use
"C:Program Files\dotnet\dotnet.exe" publish --configuration release -o c:\ExploringAspNetCore\publish --runtime active

The third part updates IIS to point to the publishing folder. The AWS CodeDeploy agent is a 32-bit application and runs PowerShell scripts with the 32-bit version of PowerShell. To access IIS with PowerShell, we need to use the 64-bit version. That’s why this section passes the script into the 64-bit version of powershell.exe.

C:\Windows\SysNative\WindowsPowerShell\v1.0\powershell.exe -Command {
             Import-Module WebAdministration
             Set-ItemProperty 'IIS:sitesDefault Web Site' 
                 -Name physicalPath -Value c:\ExploringAspNetCore\publish
}

Note: This line was formatted for readability. For the correct syntax, view the script in the repository.

If we have configured the GitHub repository to push deployments to AWS CodeDeploy, then after every push, the code change will be zipped up and sent to AWS CodeDeploy. Then AWS CodeDeploy will execute the appspec.yml and InstallApp.ps1 and the EC2 instance will be up-to-date with the latest code — no build step required.

Share Your Feedback

Check out the aws-blog-net-exploring-aspnet-core repository and let us know what you think. We’ll keep adding ideas to the repository. Feel free to open an issue to share your own ideas for deploying ASP.NET Core applications.

New Blog, New Org, and New Issue Reporting!

by Loren Segal | on | in Ruby | Permalink | Comments |  Share

Hey everyone!

My name is Loren Segal, and I will be working with Trevor Rowe on our shiny new blog here at Amazon Web Services. We both work on the AWS SDK for Ruby, and over the coming weeks, months, and years, we will be using this spot to post new updates, tips, and tricks about the Ruby SDK. We hope these posts will be informative and shed some light on what’s coming down the pipe, but we also want to get the word out about all the cool things we already support. We’re really excited about sharing all this new information with you.

And with that, we already have new announcements to make: we are changing our GitHub organization name and enabling GitHub Issues in our new organization for easier issue and feature tracking in the Ruby SDK!

A better GitHub organization name

We decided to move our GitHub amazonwebservices organization to the much shorter and easier-to-remember aws organization. With that change, we’ve also renamed the project from "aws-sdk-for-ruby" to a simpler "aws-sdk-ruby". We will be following this naming convention across our other projects to make things easier for our collaborators.

As of this blog post, we will no longer be developing against our old repository, but we will leave this old repository around so that users can still access the code. Note, however, that in about a week, we replace the contents of the repository with a README guiding our new users to the proper repository location.

Remember to update your Git remotes and Gemfiles!

If you’re currently pointing your remotes to our old organization, now is the time to update the location to the new repository. You can do so by typing the following command in your local working copy (assuming the remote is origin):

$ git remote set-url origin git://github.com/aws/aws-sdk-ruby

If you are pointing your Gemfiles to our Git repository, you will also want to update those by pointing to the new repo:

gem 'aws-sdk', :git => "git://github.com/aws/aws-sdk-ruby.git"

Note that for Gemfiles, we would much rather you point to the gem released on RubyGems.org, though!

GitHub Issues are enabled!

Finally, with our newly renamed organization, we’ve decided to enable GitHub Issues on the new aws-sdk-ruby project. You can now post bug reports, submit pull requests, and track development progress right on our issues page.

Since we’re on the topic, here are a couple of notes about submitting new issues:

Submitting pull requests: include tests

We love when users contribute code to the SDK! Really! If you’ve found a bug in the SDK and you’ve tracked down the issue and have a local working patch, submitting a pull request will help us get the fix out to our users much faster than just submitting a bug report and greedily keeping that awesome bugfix to yourself!

However, if you do plan on submitting pull requests, please try to include tests for your new code. The better the tests, the more easily we can guarantee that your patch will continue to work, and the quicker we can pull it in. Now that we are using Travis-CI for continuous integration, GitHub will happily tell us that your changes will not break the build.

Submitting bug reports: include reproduction steps

If you are having issues with the SDK not working properly, we want to hear about it and fix it. GitHub Issues now allows you to post your problems directly on our GitHub repository. If you do report an issue, please make sure to include reliable reproduction steps, as well as much extra relevant information as possible. Please make sure you do not post your AWS credentials in bug reports, however! We will never ask you for this information— that is your data.

Shiny new things!

We’re really happy about these new changes. The new blog will be here to provide new insight on what we’re up to on the Ruby team, and hopefully the new GitHub re-organization will make it much easier to contribute code and submit bugs on the AWS SDK for Ruby! Go check out our new org right now:

http://github.com/aws/aws-sdk-ruby