Series: ember-cli-deploy

ember-cli-deploy-Amazon S3

Published on Jun 03, 2016

An Amazon S3 deploy strategy is a relatively quick way to start using ember-cli-deploy that allows for plenty of customization later on.

In this episode, we spend a little bit of time setting up the ember-cli-deploy-s3 addon, and a lot of time messing around in the AWS (Amazon Web Services) console configuring our service.



$ ember install ember-cli-deploy-s3

module.exports = function(deployTarget) {
  var ENV = {

    s3: {
      accessKeyId: process.env.AWS_ACCESS_ID,
      secretAccessKey: process.env.AWS_ACCESS_SECRET,
      bucket: 'ember-school-deploy',
      region: 'us-east-1'

  return ENV;
ember deploy production


Hey and welcome back to our series on ember-cli-deploy. Last time we gave a bit of an overview as well as showing how to install ember-cli-deploy and put in ember cli deploy build. In this episode, we’re going to be talking about how to put in ember-cli-deploy-s3. And to start with it gets... it’s pretty easy at the start. We just ember install ember-cli-deploy-s3. After that, we’re going to spend most of our time messing around in the AWS console. That’s where the complications will be.

So first lets click here to S3, and it’s going to show us a list of our buckets. We’re going to be creating a new bucket for this. And we’ll call this monster-demo, since that’s the app that we’re creating. We need to select a region. If you’re in the middle or eastern part of the United States, US Standard is the good one. If you’re in the western part of the United States, then you are set with either Oregon or Northern California. Other parts of the world, just select whichever one is closest to you.

Alright, so we’ve got our bucket set up. What do we do from here? Well, first we’re going to want to set up our permissions to make sure that everyone can get access if they need to. So to decide which permissions to give, we’ll go ahead and we’ll use the ember-cli-deploy-s3. Way down at the bottom, they have a set of minimum permissions. And so we’re going to copy that and we’re going to click ‘Edit bucket policy’ here, and there we go. We’re going to have to change this out for our bucket-name, and that should be good. Except it’s not quite. So it needs a principal element.

So in the documentation we can see there are several ways to specify a principal. And we could specify everyone, but we want to be a little bit more specific than that. And so we’ll go ahead and do an individual IAM user. I’m not an expert in this, I just know that that’s what I had to do. I’ll show you how to get access to that account id.

So we’ll go to our management console, we’ll go ahead and open up another one so we don’t have to exit out of that policy editor, and we’ll go ahead and go to our security credentials, and... it shows this every time, so I guess I should click that. I’ll go ahead and go here. And notice that I’ve created some users and we’ll go ahead and create a new user. This will be ember-screencasts. And we’re going to generate an access key for each user. So it’s going to show these only once, and I’m not going to record it while I’m showing them. Alright, I copied those down to a safe spot, and I can also download them. We close this, we show that there is a new user, and here is our ARN. And so that is what’s going to go here. This is what’s in their ARN. So we’ll go ahead and copy this and paste this into our bucket policy, and then we’ll replace their ARN with ours. We’ll save that, and seems to be good.

In the S3 addon, it also gives us stuff for a sample CORS configuration. However, I haven’t needed that yet. Go ahead and let me know what breaks for you guys that’s fixed by doing this CORS configuration and I’ll add that to the comments on the side. But if you do decide to add CORS, the button is right over here, right to the side of ‘Edit bucket policy’ in the ‘Permissions’ tab.

Now we need to set up the variables for our S3 addon. Go ahead and copy this, and then we’ll put it in deploy.js. Because we’re putting it up here, we’ll need to make the format a little bit different. There we go, that’s great. Some of these, like the bucket, we can just put in there. So this will be monster-demo. If you’re wanting to have separate buckets for development and production, then you may want to set that down here. But we’re just going to keep it simple for now. And we’ll going to set our region. This is not quite the region... well it’s the region that we selected, but it will be named differently. So we select this as US Standard. This we’re putting it as us-east-1. You’ll just have to look that up. Now for these other two since we do not want to share them, we’ll be using .env. And so to install it, there is an ember-cli version of this, but it works a little bit differently. It can’t be put in to things like deploy.js which is using... well, it’s not using the es2015 module system, which is what I believe ember-cli.env relies on. So for config.deploy.js and config.environment.js, you have to use the regular .env.

So we’ll install the npm one, and now that it’s done, we’ll be able to see that we can create a new file called .env. And make sure to gitignore it, and now it’s gitignored we can do things like AWS_ACCESS_KEY, and we’ll set it to an actual key, but I’m not going to show you mine. Then at the top of our deploy.js, we’re going to require('dotenv') and call load on that. And that’ll get us stuff in our process.env. So process.env and then the name.

Now we’ll call ember deploy production, and notice we don’t have to save our changes in order to be able to deploy them. That’s something interesting to keep in mind. Also we’ve got two steps in the deploy process, the build and the upload to s3. We’ll keep on adding to that as we go. Now let’s go check to make sure that worked.

So we’ve got our name monster-demo, and there are two ways to access this. The one that we’ll use is the name, And oh-oh, we’ve run into a problem. So there are two things that we’re going to have to fix in order to get this working. And the first one is that notice there’s no index here. We’ll have to go to our s3 environment keys and add in a file pattern to say this is what we’re going to upload, anything that ends in this. The original one is more restrictive than this. So this will upload our index.html. We can show that here. So now we have an index.html, but there are going to be some problems. One way to fix this is in your environment, set the locationType to hash. Another way if you want to use the history location api is to set up some redirection rules on s3. We’re going to be using the hash. So we’ll take that change we made earlier and we’ll deploy it to production. And when we reload this page, we’ll see that it is now working.

Of course we’re not quite done yet. If we go to a page that requires contacting the server and we make a request, we see that it’s making it to here. So we want to redirect the API. But since this episode is already over ten minutes, we’re going to do that next time. I’ll see you then.


Subscribe to our mailing list