Why I think we should all use immutable Docker images

Docker is awesome. But the Docker technology can be used many different ways depending on the use case, the technology context and the developers or devops’ praxis.

In my point of view that containerisation technology requires most of us to change our mind on the way of seeing ops in our domain. In most of the use cases, there is a misunderstanding of the benefits of this technology if you are not using immutable images.

We probably have to change our mind

Except a very few like Google that runs containers since almost 10 years, we used to/are using a server or a VM to host our web applications. Simply ask (if it’s not you) the “system” or “devops” team to install and configure whatever it is needed to run that replaces with the language you like web application. Once they finished, we can now updates the source code deployed on the server by using Capistrano or any other deployment tool. The result is that the code is updated on the web server(s).

Then, the Docker popularity exploded. Everybody started to use it and most of us replicated the same logic: lets have a container running the web server and mount the source code from on the host or use a data-container. In that case, we are using Docker only to ease the server setup.

This setup is using what I name mutable images because if you change the contents of the mounted volume, then you change the behaviour of the container. That means that if you run that same image on another  machine, then the container will potentially have a different behaviour than the one running on the other machine. We do have a kind of portability, but we don’t have the predictability at all.

Why immutable Docker images?

When we are talking about software design, the literature around immutable objects is vast. The devops culture is about joining the devs and the ops, so why not introducing immutability here too? An immutable image is an image that contains everything it needs to run the application, so obviously including your source code.

Continue reading Why I think we should all use immutable Docker images


Managing monolithic repositories with composer’s path repository

Composer now have a new repository type in addition to, among others, the well known vcs for instance: the path repository. The goal if this repository is to be able to manage dependencies between applications and packages in a monolithic repository.

A monolithic repository?

The first question can be: why a monolithic repository? There are many blog posts and videos around about why such a code repository can be extremely useful for your project and your team, but we can quickly summarise that in some cases you’ll find at least these advantages:

  • Reduced bootstrap cost as new starters just need this repository
  • Easier to have cross-applications patches (via a single pull-request for instance)
  • You don’t need to download dependencies as they are here 😉

Obviously there are also some potential problems such as the ease of BC breaks between your libraries/applications and also shared responsibility, but that’s more related to the developers than the tooling.

Continue reading Managing monolithic repositories with composer’s path repository


Docker running on OVH VPS (Ubuntu 14.04)

Warning. It looks like that it isn’t true anymore for VPS 2016. See this comment.

For testing purpose, you may want to install a Docker server on an OVH VPS. This short article explain you how to make Docker running on a VPS with an Ubuntu 14.04 system (this may be the same for Debian users).

First of all, as we need to use an official kernel, do not use VPS Classic. Only the VPS Cloud that is running on VMWare let you use another kernel instead of there customized one.

Continue reading Docker running on OVH VPS (Ubuntu 14.04)


iOS Swift and AFNetworking: Get response data and status code in case of failure

If you're using the AFNetworking library to perform HTTP queries in an iOS or OS X application, either with Objective-C or Swift, there's no simple way to get the response content in case of failure.

Let's asume the following POST query that send and receive JSON:

We'll now talk about the failure listener, and how to get the response status code and then the data.

Get the status code

The NSURLSessionDataTask object as a response attribute which is a NSHTTPURLResponse object. The status code, which is stored in the statusCode attribute, can simply be accessible this way:

Get the response content

Getting the response content is a little bit more complicated: we have to create our own response serializer. In this case, we’ll override the responseObjectForResponse method of the AFJSONResponseSerializer.

The following implementation simply add the result data in the userInfo of the error object which is accessible in the failure closure:

Then, you’ve to change the response serializer you want to use with your AFNetworking manager:

Based on that we can access to the response content using the error’s userInfo:


JMS Serializer: serialize camel-cased fields without them being renamed

Using JMSSerializer (or its bundle) serialized field are renamed by default to the underscore-separated words naming convention. If like me you prefer camel-case naming and you want fields serialized as it, there’s two solutions.

1. Set serialize name for each fields

You can use the @SerializedName annotation, serialized-name XML property or the serialized_name YAML configuration to fix the name that will be used for each fields.

2. Change the whole naming strategy

If like me you don’t want to set the serialized name for each field, you can change the naming strategy by your custom one or the simple IdenticalPropertyNamingStrategy that don’t rename fields.

The first solution is to set the naming strategy while creating your serializer using the SerializerBuilder:

The second solution if you use the bundle is to override the jms_serializer.camel_case_naming_strategy.class parameter in your app/config/parameters.yml file.


Sonata Admin: Create ACL on object created outside of Admin

If you're using Sonata Admin and Symfony's ACL, you can extends Sonata Admin with the CoopTilleulsAclSonataAdminExtensionBundle. Using it, lists just contain data the logged in user has right to view. Thanks to the ACL editor, you can simply manage ACL inside your application and in the Sonata Admin.

It's perfectly working when objects are created inside the Sonata Admin, but don't works when you're creating them in a custom controller. 
To make it working, you just have to create the ACL using the Sonata Admin Security Handler.

Let's imagine you've a controller that is handling a form, and we've like the following code:

Now, you just have to get the sonata.admin.security.handler which is an alias of the current security handler (look at SonataAdminExtension.php#L108) and update ACLs after persisting your model. If your Admin service for this model is named foo.barbundle.admin.model, use the following code:


PHPUnit: MySQL “Too many connections” error

Even if it's the best idea to write tests that need a real database connection, sometimes it's something needed. If you're using Symfony2, you can simply follow the "How to test Doctrine Repositories" part of Symfony documentation to do that.

But if you're running a large amount of tests you'll get the following MySQL error:

SQLSTATE[08004] [1040] Too many connections

This means that you reached the maximum number of simultanous connections (max_connections parameter in my.cnf). To fix that behaviour, I had to change the processIsolation parameter of PHPUnit in the phpunit.xml file, like this:

backupGlobals = "false"
backupStaticAttributes = "false"
colors = "true"
convertErrorsToExceptions = "true"
convertNoticesToExceptions = "true"
convertWarningsToExceptions = "true"
processIsolation = "true"
stopOnFailure = "false"
syntaxCheck = "false"
bootstrap = "bootstrap.php.cache" >


Symfony2 Form, PATCH requests and handleRequest: Form is never valid

From Symfony 2.3 we can use (PR #7849) PATCH requests with the Form component to submit a part of the form which will override the form default values. This is really helpful moreover using FOSRestBundle and its listeners !

With this configuration, to make a user available to PATCH its profile using REST API, you simply have to write this few lines:

But the form is never valid…

In fact, you’ll never have a valid form if you let it as it’s. The problem is that the form is never submitted by the HttpFundationRequestHandler because the current request method (PATCH) isn’t a GET or POST, which are waited by the form (see L39).

Two solutions

You’ve 2 simple solutions, use the submit method, or set the method option on the form.