When not to use containers – configuration options

When not to use containers – configuration options

On a recent client project we were implementing Single Sign On using Ping and an LDAP server. An LDAP (Lightweight Directory Access Protocol) server is used to find details about a user by using a standard hierarchy structure of root-country-organization-organizational units-individuals. The client decided on an open source ldap server which was very easy to setup and configure.

We always recommend containers as containers on fargate are automatically replaced if they go down. One of the problems with containers is that you cannot get onto the file system which in the case of the LDAP server is a problem as you cannot restore the configuration unless you have access to the fileserver. We could have written an API so the LDAP server could have it’s configuration changed but this was too expensive an option for the project. If the container had an api to change the configuration then a container would have been possible.

We also wanted to put the ping server in a container as well as there was support for docker. For the same reasons as the LDAP server we needed to upload the configuration if the server went down.

We at first wanted to put both the ping server and the LDAP server on containers but in the end we went with plain old EC2.