Recently some of our Elastic Beanstalk deployments suddenly started failing. It turns out it was a change to EB's configuration validation which caused some misleading error messages.
Recent Posts by Matt Bryson
Yesterday, iDetailAid attended the Amazon Web Services (AWS) Summit in London's ExCeL centre, along with 6,000 other customers and partners of Amazon.
With the release of
MySQL 5.6, there was no longer a default user account with an empty password. For security reasons the
root account is now allocated a random password when MySQL is installed, which is written to a log file.
You then look up the password from the log file, and use it to login and change it to something else...
$ sudo grep 'temporary password' /var/log/mysqld.log $ mysqladmin -u root --password=RANDOM_PASSWORD_FROM_LOG password myNewSuperSecretPassword1!
This is all well and good, unless you are automating deployment of MySQL. We use
ansible to spin up our local dev servers, and as soon as we upgraded MySQL, all our MySQL commands started failing as they could no longer authenticate.
There was no obvious way to install with a predefined password, or no password, so we came up with the following to automate setting up MySQL.
I was trying to set up SSH Multiplexing on our CI server to speed things up a bit, but for some reason it always failed to use the shared connection.
So, last week I was writing a post about cleaning up after docker, and I got a bit carried away and ended up deleting a data container. The container was no longer running, but it's docker volume was still in use by other running containers.
Thankfully, I didn't use the
-v flag (which removes the containers volumes as well - although volumes in use wont get removed), so I still had all the data, I just had lost the container that created it.
The problem is, docker references the volume via the container when mounting it as a shared volume. As I had deleted the container, I could no longer reference the volume.
Thankfully there is a very simple solution to get the volume mapped back to the data container.
We have some
ansible scripts that deploy
docker containers on to various environments. All has been going fine until this week, when we fell foul of the untidy teenager that is docker!
Our deployment was failing as the box had run out of disk space. Turns out you need to tidy up after docker...
Sometimes EB fails to deploy and times out with a generic error:
Unsuccessful command execution on instance id(s) 'i-********'. Aborting the operation.
As of yet there is no clean way to get out of this, but here are the top 3 ways that we have got it to work - depending on your needs...
OSX quick look is great, but it only supports a limited number of text files.
We often get an issue with our MEAN vagrant dev environments where a previously working server will fail to connect to the mongo db the next time a developer does