Russ, Ilya, Natalie and I just got back from a long weekend at our data center in Chicago. We were working with Server Central to do a major switch upgrade in both of our cabinets. Every time I go to the data center it’s a lot of fun, so I figured I would share some of the upgrades with you.
Migration to Juniper Switches
We used to run on Cisco switches. As we added more servers we started to notice some rare, but impacting, packet drops on the network. Beanstalk is pretty demanding when it comes to bandwidth and network, so we made the decision to upgrade the switches in both of our cabinets. Due to Server Central’s experience (they manage our switches) we went with Juniper, which were highly recommended.
In each cabinet we have a pair of Juniper EX4200 switches, which are interconnected over a 128 Gbps backplane. This allows us to use ethernet bonding on each server so in the event that a switch dies, we are still up and running.
The actual migration was tough to plan. Our goal was to migrate every server in both cabinets with zero downtime. It was tricky, but on Saturday we managed to move every server one at a time, with only a couple blips of issues. Most of this was only possible due to our use of bonding on the interfaces. If you were working this weekend and noticed the issues I apologize and promise that the upgrade was well worth it.
Upgrade to 10 Gbit switches
Another awesome upgrade this weekend was the 10 Gbit switches. Since we moved to Server Central we’ve been using 10 Gbit crossover for all of our machines that handle repository traffic to our storage servers. You can imagine how messy this gets as you add servers. With the addition of the Juniper EX4550, we now have room to upgrade all of our servers to 10 Gbit for storage traffic, including our web machines and background processes. This will go a long way in providing faster imports, exports, caching and just about anything else that touches repository data. We’re super excited about this. Surprisingly, the new 10 Gbit switch improved overall latency as well, down to 0.035 ms pings between servers.
Other upgrades
While we were there, we made some time to organize some of the servers better in the cabinets. We also added a new backup server and doubled the capacity of our already generous ZFS storage environment.
Overall the trip was a big success and a lot of fun. We had time to hang out with some of the team at Server Central, which always guarantees a good time.
Solid integration with many services has been at the core of Beanstalk since we started. Before we even launched out of beta over five years ago we had integration with Basecamp, Lighthouse and Fogbugz. Over the years we’ve continued to add and improve our integrations to help make your development process smooth and connected. Of course, keeping up with all of the integrations is hard work.
Today Zapier, which is like a match maker for web services, announced support for Beanstalk, making it easier than ever to integrate Beanstalk with almost 200 services instantly.
If you are not familiar with Zapier, it is pretty simple. You choose the service you want to use as a trigger (like Beanstalk), then choose another service which should take an action when that trigger is pulled (like posting a to-do). For instance, we use Zapier at Wildbit for Twitter to Hipchat integration. When a new @ mention comes in which mentions our products, we post it to a Hipchat room. It works perfectly and only took a few minutes to set up.
Heroku makes it easy to deploy your application hosted in Git repos, but Subversion and Mercurial users have to resort to command line trickery in order to deploy. No more!
Beanstalk now supports Heroku deployments for Subversion and Mercurial without you having do any extra steps – just configure the deployment server and start deploying.
For Subversion, you will need to specify the application path in your repository:
We hope you find this useful! Let us know what you think.
Here’s a small batch of improvements for SSH deployments to make your life a bit easier.
Specify working directory for shell commands
By specifying a working directory you are setting a context for your shell commands to be executed in. So you don’t have to write your commands like this anymore:
Instead you can do this now:
If you need to go to a different directory on some individual line, plain cd /other/dir command will work.
Real-time Transfer Log updates for long-running commands
Previously when some long-running shell command was in progress you wouldn’t see any output until the command had finished. That created problem for those of us with complicated deployment scripts (eg. Capistrano) that are executed by single command but output a lot of data while running.
From now on Transfer Log for SSH deployments shows the output immediately as it’s generated by the shell command, allowing you to have instant overview of current deployment state.
Today we release another highly requested feature – the ability to deploy your Mercurial repositories to FTP/SFTP/SSH servers and cloud services (S3, Rackspace Cloud Files).
This finally makes Mercurial a first class citizen in Beanstalk and allows Mercurial users to enjoy the same deployment functionality that Git and Subversion users were enjoying for years.
To start using deployments, visit the Deployments tab under your repository.
HTTPS access for Mercurial
In addition to deployments, Mercurial will also have HTTPS support (finally, as well). We admit that Hg support was very limited with SSH only, since most people use Hg with HTTPS. Starting tomorrow morning, you will see the HTTPS URL option on your Hg repository activity page. This will make it much easier to get started with Mercurial, especially in Windows.
Let us know what you think!
Update: Mercurial HTTPS access is enabled for all accounts.
At Wildbit, we’re big fans of what the team at Heroku is doing. I’m really proud to announce that Git deployments in Beanstalk now integrate nicely with this great service.
Heroku is an application platform that allows you to deploy your web app to the cloud, from scratch, in a matter of minutes. Our integration means that you can now trigger a deployment of your application automatically by pushing to your Beanstalk repository or by clicking a button in the Beanstalk UI, just like you’re able to do now with FTP, SFTP, SSH and recently Cloud FIles and Amazon S3.
How it works
First you will need to create a Heroku application if you don’t already have one. You will also need your Heroku API key which is available on the My Account page.
After you have the application name and API key, you can go to Beanstalk to create a new deployment server and pick Heroku as the server type.
After this step, Beanstalk will generate a unique public/private RSA key pair and add it to your account, so that Beanstalk is able to trigger deployments of your application.
What’s next?
That’s it! After you’re done with the form above, you can start deploying your application to Heroku. Our regular tools like Release Notes, automated deployments, Transfer Log, deployment history and rollbacks will become available to you.
One important thing that can make a big difference is that if you deploy to Heroku through Beanstalk you can have several users deploying your application without them having direct access to your Heroku servers, since Beanstalk will enforce the access rules you define.
Beanstalk also allows you to create multi-server environments that make it possible to deploy your assets or static files to your S3 or CloudFiles servers while your application is being deployed to Heroku.
We’re really excited about this and would love to know what you think!
Today we release a feature that was often requested by our customers. You can now filter the files that are deployed from your repository to your server using regular shell patterns.
This allows you to skip all of the changes and files that match a certain pattern when a deployment is triggered. For example, you can ignore all files with the .log extension in all the directories by using the **/*.log pattern.
In this pattern **/ means “in any directory” and *.log means “any file or directory ending with a .log”.
We included an inline help link near the excluded paths form that shows some of the most commonly used patterns explained.
We hope you like it!
Beanstalk allows designers and developers to store source code, track changes, and collaborate with team.
