Archive for the ‘Uncategorized’ Category

Creating a staging + production environment for a Node.js service on AWS Elastic Beanstalk with Cloudbees as CD service in 51 steps

February 24, 2015 Leave a comment
  1. In AWS:
  2. Login to AWS, add a new AIM user called Jenkins_EBS_Access (or whatever name makes you happy), save the credentials, attach the following policy to the user as an inline, custom policy:

  3. {
    "Version": "2012-10-17",
    "Statement": [
    "Sid": "Stmt1414820271000",
    "Effect": "Allow",
    "Action": [
    "Resource": [
  4. Go to S3, add a new bucket called deployments
  5. Add two plugins in the Jenkins manage plugins area:
    1. Cloudbees Amazon Web Services Credentials plugin
    2. Cloudbees Amazon Web Services deploy engine plugin
  6. In Cloudbees:
  7. Create your Cloudbees repository, commit a working node.js service
  8. Goto builds and add a new build
  9. In build configuration, below deploy now click on Advanced, remove the default cloudbees host service, and add an Elastic Beanstalk deployment, create a new credentials entry and add the credentials that you saved for the AWS user you just created.
  10. Click add application
  11. Pick your region (us-east-1 is the default and cheapest option)
  12. In S3 bucket, enter deployments/${BUILD_NUMBER}
  13. In application name, enter service
  14. In version label, enter ${JOB_NAME}.#${BUILD_NUMBER}
  15. In environment name, enter myservice-stg
  16. Click “promote builds when”
  17. in name enter production
  18. pick the star color you want (I like green)
  19. Click “only when manually approved”
  20. Add action “deploy application”
  21. Repeat process 8 – 13 (minus the add new credentials step, just use the ones you already added)
  22. In environment name, enter myservice-prd
  23. In build->execute shell->command, enter the following:

  24. node_version=0.10.21
    if [ ! -e nodejs-plugin-$ ]
    unzip nodejs-plugin-$
    tar xf node.tar.gz
    mv node-v* node_lib

    rm -rf target
    mkdir target

    export PATH=$PATH:$WORKSPACE/node_lib/bin

    npm install
    npm install time
    npm install grunt grunt-cli

    export PATH=node_modules/grunt-cli/bin/:$PATH
    #export PATH=$PATH:node_modules/grunt-cli/bin/


    rm -rf target/app.war
    cd dist
    zip -r ../target/app.war .

  25. Note that you might need to change the node.js version number, and also the last couple of lines, if your directory structure is a bit different than mine.  My code uses grunt and deploys to a directory called dist
  26. Again, repeat steps 8 – 13
  27. In environment name, enter myservice-stg
  28. In post build actions, in Archive the artifacts, change *.zip to *.war
  29. Click save
  30. Click Build NOW
  31. Go to the build console output view and make sure there are no errors in the build
  32. Your node.js main file should be called app.js or server.js, there are the app names which AWS calls by default (configurable), or npm start should trigger your app if all else fails.
  33. Once the build has finished, you should see that the app has been uploaded to s3, but you should expect to see a failure which says: “No Application named ‘service’ found”.  This is ok, we have not created the app yet, but we now have the app in S3 and this is where we’ll go next.
  34. Go to AWS S3, to the deployments bucket, you should see a new file under a folder with your current version number called service.  Click it and hit properties.
  35. Copy the link url
  36. Go to Elastic Beanstalk, and create a new application.  The name should be the same name you entered in cloudbees build, in the Application Name field.
  37. Now create a new web server
  38. select node.js platform, and keep the load balanced configuration
  39. under application version, pick s3, and paste the s3 bucket URL you just copied
  40. In environment name, enter the environment name you entered in cloudbees (myservice-stg)
  41. next, next
  42. In instance type pick t2.micro, this is actually cheaper than t1.micro and has better performance
  43. Go to EC2 -> key pairs (pick from the left side list), and create a new key pair.  You will automatically download a PEM file which you will later use to access your instances if you wish
  44. Back in Elastic Beanstalk, refresh the EC2 key pairs listing and pick your newly created key pair
  45. In environment tags, add the following tags:
    1. key: type, value: service
    2. key: class, value: staging
  46. These tags will let you report on usage later on
  47. Launch your environment
  48. Repeat the process, but this time with myservice-prd as the environment name, and in the class, enter production
  49. In Cloudbees, Click Build now.  The build should now succeed, and auto-deploy to the staging environment.
  50. Once it’s deployed and you see in AWS that the staging service is updated with the new build, go back to Cloudbees and
  51. Click the new build, go to Promotion Status, and on the right hand, side, click Force Promotion
  52. The build should now be promoted to the production environment
  53. Voila, you now have a CD process with staging and production environments on AWS

Setting up SSL for AWS Cloudfront : problems and solutions

July 27, 2014 Leave a comment

You can follow this blog to set it all up, the problems I’ve encountered and their solutions are detailed below:

Q: What’s the command I have to run (under windows)

A: aws iam upload-server-certificate –server-certificate-name mycompanyname –certificate-body file://mycert.crt –private-key file://mykeyfile.key –certificate-chain file://customizedcertfromgodaddy.crt –path /cloudfront/justanameIchose/

Q: How do I customize my godaddy certificate to be compatible with AWS

A: AWS requires a subset of what’s included in your certificate authority’s certificate. The certificate I got from Godaddy (that’s THEIR certificate, not the one they issued for my company, i.e. the one named gd_bundle-g2-g1.crt) had 3 sections in it, I had to remove the first two.

Q: Got an error: A client error (AccessDenied) occurred when calling the UploadServerCertificate operation: User: arn:aws:iam::xxxxxxxxx:user/yyyyyyyy is not authorized to perform: iam:UploadServerCertificate on resource: arn:aws:iam::xxxxxxxxx:server-certificate/cloudfront/zzzzzzz/qqqqqqqq

A: This happens because the user whose credentials you supplied does not have enough permissions to perform this action. You should give it all permissions as explained in the blog post I referred to

Q: Got an error: A client error (MalformedCertificate) occurred when calling the UploadServerCertificate operation: Unable to parse certificate. Please ensure the certificate is
in PEM format.

A: In my case, this had nothing to do with the certificate format, it just happened because I removed the file:// prefix in the aws command and this is required. Would have been much clearer if Amazon had bothered to specify this error instead of a general “your format is wrong”, which has nothing to do with the real problem, but c’est la vie.

Q: Got an error: A client error (MalformedCertificate) occurred when calling the UploadServerCertificate operation: Unable to validate certificate chain. The certificate chain must start with the immediate signing certificate, followed by any intermediaries in order. The index within the chain of the invalid certificate is: 3

A: This happened because I did not remove the unneeded parts of the godaddy certificate. See question above.

Q: Got an error: argument –server-certificate-name is required but I look at my command and it’s there

A: The problem might be with the source from which you copied the command string, sometimes — gets replaced by a similar character which visually looks the same but is not the same ASCII code.  Just delete all the – signed and retype them yourself

Once this is all sorted out, you can continue to follow the blog post and all should work.

Categories: R&D, Uncategorized Tags: , , ,

Updating an SSL certificate from Godaddy (or other) in Cloudbees

January 10, 2014 Leave a comment

So you managed to survive a whole year after getting your certificate, congratz, and now you need to replace it with a new one because the old one is about to expire.   Here are the simple steps to do that:

  1. Go to Godaddy and ask them to issue the new certificate.  You can use the CSR file you used last time you asked for a certificate.
  2. Download the certificate files, you’ll get two files with a CRT extension:  your site’s certificate, and go daddy’s CA certificate
  3. Append your site’s certificate to go daddy’s.  On unix, this would be cat your.crt godaddy.crt > finalcert.crt
  4. Validate that the certificate you created works for your deployment:
    bees app:cert:validate -a yourcloudbeesaccount -cert ./finalcert.crt -pk ./thekeyfileyougotwhenyoucreatedthecsrfile.key
  5. Update your deployment with the new certificate (you need to know the name of the ssl service you created on cloudbees, check your production app on cloudbees for this setting):
    bees app:router:update yoursslservicename-ssl -cert ./finalcert.crt -pk ./thekeyfileyougotwhenyoucreatedthecsrfile.key

That’s it, you should now have a valid new certificate live.

Categories: Uncategorized