On the Delicious Brains site they've posted a tutorial showing how to create a command line daemon that will emulate the Amazon Web Services SQSD handling. The SQSD is a worker daemon service that Amazon offers as a part of its Elastic Beanstalk support.

Sometimes when you’re building a project there are parts of the architecture that exist on production that don’t exist on your development machine. Those missing parts (like proprietary software that’s specific to your hosting provider) can sometimes mean unwelcome surprises when you deploy to production.

Recently as part of my work on Mergebot, I decided to address this. My local machine was missing the AWS Elastic Beanstalk Worker Environment SQS daemon (known as SQSD). AWS isn’t open source so there’s, unfortunately, no official way to replicate it. So I decided to build a small PHP command line (CLI) app to attempt to replicate its functionality. In this article, I’m going to cover some of the aspects of creating a command line app in PHP and explain how I implemented them for my replica SQSD CLI.

He starts off with a brief overview of the Laravel queue worker and how it compares to the SQSD functionality. He then starts in on the code to create the daemon (outside of a framework) and adding in the while loop to keep it running as a daemon making use of the SQSD Worker class as a base. The post ends with some instructions on packaging up the command line tool using the phar functionality already included in the PHP language.

On the DeliciousBrains.com site they've posted the second part of a series covering the scaling of a Laravel-based application using Elastic Beanstalk (part one is here).

In my last article we decoupled Laravel and got it ready for deployment to the Elastic Beanstalk architecture. However, before we race ahead to actually deploying our code to Elastic Beanstalk we need to do some preparation first. Specifically we need to set up some other AWS services that will be used by our Laravel app. These include: Virtual Private Cloud (VPC) to keep our infrastructure secure, Relational Database Service (RDS) for our MySQL database and ElastiCache for our Redis cache

With these “supporting” services up and running we can finally move on to deploying our Laravel app to Elastic Beanstalk.

They start off by walking you through the creation of the VPC on the AWS services using both public and private subnets. With that in place they move on to the RDS setup, configuring it to host their MySQL database and making a test connection. Finally they set up the ElastiCache instance for the Redis handling finishing out their "supporting services" setup in AWS.

Piotr Pasich continues his series covering the integration of Docker, Elastic Beanstalk and Codeship to create a workflow for shipping and releasing code. In the first two parts of the series he set up most of the technology involved and hooked some of it together. In this latest article he finishes the process, connecting CodeShip with GitHub and your tests.

Today I will walk you through combining all the pieces together and automating the process fully. A continuous integration system will be placed between developer’s environment and final servers. I’ll present how to achieve all of that with Codeship. What make me choose this particular mechanism? The simplicity of setting up, number of additional tools ready to use without installation and finally the fact that it isn’t time consuming.

He shows how to connect CodeShip with your GitHub repository. He shows how to create a new CodeShip project to handle the build complete with a screencast to ensure things are set up as they should be. He includes a bit of "magic" you'll need to do with the CodeShip configuration to get it to work with the Docker setup, but the change is minimal. He also shows you how to set up the execution of your tests and how to see what failed when a build is broken. Finally he shows the process for setting up the deployment to the hosting provider (in this case Digital Ocean) and how to configure your Amazon credentials right in the interface.

Piotr Pasich has posted the second part of his series showing you how to set up an automated deployment process for an environment that includes an Elastic Beanstalk instance. In this part of the series be builds on the process created in part one and shows the setup and configuration of the Beanstalk instance.

In the previous part we set up a dedicated Symfony application on Docker virtual containers and prepared environments that may be transferred between developers during project cycle. The next step is to prepare the application for pushing into the cloud. There are many options available on the market – Heroku, DigitalOcean and, my favorite, AWS Elastic Beanstalk.

He walks you through the Amazon side of things first, getting the Beanstalk instance set up through the AWS control panel, selected from the AWS list of services. He goes through the options you'll need to configure to get the instance all set up and running including the resources to allocate and instance type (t1.medium is recommended). He then helps set up some of the necessary environment variables for configuration information and a bit of a hack to Symfony that lets you override local parameters with ones coming from the environment. Finally he configures the Beanstalk application and setting it up for automated deployment.

In the X-Team blog they've posted about deployment, specifically combining Docker and Codeship to push an application (in this case a Symfony2 one) out to an Amazon Web Services instance.

Just imagine. It’s Friday afternoon, the team has just finished a new feature which should be deployed to the servers before the weekend. And you are the lucky guy who is responsible for completing the task. Generally, it shouldn’t take more than five minutes. Well, what could possibly go wrong. [...] In the attached video, you’ll find an introduction on how to setup and automate deployment with Docker, AWS Elastic BeansTalk and Codeship in 90 minutes. Don’t miss a Friday night party ever again!

The tutorial comes in the form of a video screencasting the whole process, all the way from setting up the AWS instance and Codeship account out to the configuration and software you'll need to use Docker to build the containers and make the deploy.