Mule Meets Zuul: A Centralized Properties Management – Part I, Server side


It is always recommended to use Spring properties with Mule, to externalize any configuration parameters (URLs, ports, user names, passwords, etc.). For example, the Acme API from my previous post connects to an external database. So instead of hard-coding connectivity options inside my application code, I would create a properties file, e.g., as follows:

Obviously, as a developer, I would use a test instance of Acme database to test my application. I’d commit the code to the version control system, including the properties file. Then my application would begin its journey from the automated build system to the Dev environment, to QA, Pre-Prod, and finally Prod – and fail to deploy on production because it wouldn’t be able to connect to the test database! Or even worse, it would connect to the test database and use it and no one would notice the problem until customers placed $0 order for an Acme widget which would normally cost $1000, all because the test database didn’t contain actual prices!

Sure, I could just follow the recommendations on our web site and create multiple sets of properties, e.g.,, etc. But instead of solving the problem, it would create a few new ones.

  • First, those properties must still be packaged within the application. Needless to say, IT guys would never give me the credentials for the production database, so I’d have to provide instructions for them on how to modify the properties file AFTER the application is deployed on the prod platform.
  • Second, if (or rather WHEN) any of those properties will need to be changed (for example, the production DB is migrated to a new ), the whole process has to be repeated. And don’t forget about passwords and other sensitive data that should never appear in the code as open text and have to be encrypted.

It seems like every single customer I’ve worked with has this problem. And there was no convincing solution until one of our customers told me about an application called Zuul.

As the description on the Zuul web site says, “Zuul is a free, open source web application which can be used to centralize and manage configuration for your internal applications. It enables your operations team to control changes and your developers a centralized place to organize settings.” Of course, I couldn’t resist the urge to download it and try it out with Mule.

The installation and configuration of the Zuul server was pretty straightforward. After all, Zuul is a standard web application, so I just deployed it to my local Tomcat instance, alongside with MMC which was already deployed on it. I configured the database settings to point to my local MySQL instance. For the LDAP server I used OpenLDAP. I had to download and install the Unlimited Strength JCE Policy Files. Then I started Tomcat and opened the Zuul URL in my browser and logged in as administrator.

The first task is to create my environments. Navigating to Administration->Environments menu, I see three environments, prod, qa, and dev, which Zuul creates by default. Just what I need! Moreover, the prod environment is red – which means, only someone with Administrator privileges can mess with it.

And while we are in the Administration screen, let’s create a new encryption key for our password values. Administration->Key Management, then click on Create New... button and populate the form:

And now we can create our properties. Select Settings->Create New, give it a name, e.g. AcmeProperties. On the next screen, you’re given the option to create a new properties set from scratch, or to upload an existing properties file. Since we already have for our dev environment, let’s just use it. Select dev environment on the left tab, then click Upload File button:

Upload and you’ll see the following screen:

Now we can encrypt the database password. Just make sure the correct key is selected, then click Edit and select Encrypt.

To finish the server setup, we replicate this set of properties on the qa and prod environments. Select qa tab, then click Copy Existing, then in the Search text box type dev. Your properties set "/dev/" will be highlighted. Click Copy button and now you have the identical set of properties in qa. Repeat the process for the prod environment. Change properties values on each environment accordingly.

This concludes the server setup procedure. In the next post, I will show you how to configure Mule to use Zuul properties management.

See part II of this post.

We'd love to hear your opinion on this post

15 Responses to “Mule Meets Zuul: A Centralized Properties Management – Part I, Server side”

  1. Pretty surprised that you didn’t include a link to Zuul in the article. For readers who want to check this tool out, here it is:

    • Raul, thank you very much for your comment! For some reason I forgot to add the link to the Zuul web site. It is fixed now!

  2. Thanks for sharing about Zuul, never heard of it. It indeed looks promising… eagerly waiting for the second part of your blog.

    For the record, Spring properties support the notion of optional files. This allows the following approach: the application packages and loads an optional /etc/my_app/ The latter file can be generated by Chef or Puppet on the target server, using the values relevant to the environment. This approach avoids storing non-dev credentials into the project (hence its SCM), which is a big no-no.

    • David, you are right, optional property files are used widely. However, Zuul greatly simplifies the task of managing property sets, it makes it easier to propagate your changes to other environments, and last but not least, it has a nice user-friendly GUI 🙂

  3. Pretty cool. Thanks for sharing, this really help to manage and centralize all configuations. I will try it now! 🙂

  4. Thanks for the post – Zuul looks interesting. In these cloudy times I wonder about networking and single points of failure. Any suggestions?

    FWIW we don’t follow the naming recommended on the Mule we site. We package with the app and then override those with $MULE_HOME/conf/ in other environments. These then come from Puppet.

    I like David’s suggestion as a possible improvement for our approach.

    Surly no one has their test DB accessible from prod right?

    • Geoff, you raise a valid concern, Zuul downtime can potentially affect all your environments and cause a major disaster. Perhaps it is possible improve the client code so that it can talk to multiple Zuul instances (I will cover the client side in tomorrow’s post 🙂 ), or potentially add a load balancer in front of a couple of Zuul instances.

  5. Great article.

    We have been using Zuul with our Mule applications for some time. Great way to manage configuration properties from a central location. We wanted to protect sensitive configuration data with minimal setup and Zuul provided that.

  6. Eugene, Thanks for bringing this up! Zuul is really helpful. I’m not sure if you’ve met Mike Cantrell or not. He’s an architect at Confluex and he built Zuul while working on a Mule ESB project. He’s going to be at Connect in May with us. I’ll introduce you.

  7. Geoff and Eugene, the zuul-spring-client has a feature that prevents downtime when the zuul server is unavailable. It was added for exactly this scenario.

    From :

    The zuul:file-store element is optional. It caches copies of the files (with encrypted values) to the local filesystem. If configured, it will be used as a backup strategy if the zuul web services are unavailable. If left un-configured, the application will throw an exception upon startup if the service is not available.

  8. I’m the author of Zuul and Mule was actually one of the first things I applied it to. It makes a great fit. It’s really nice in an audited environment. I’m happy to see other finding value in it.

    Look for some upcoming enhancements and bugfixes soon. If you have ideas or problems, I’d appreciate the feedback!

  9. How about adding Zuul functionality to Mule Managment Console? MMC is already a central point for all mule deployments across organization, so it would be perfect to have ability to modify dynamically environment variables from there.

  10. Sounds promising, wasn’t sure whether zuul still works as it was 2+yrs old forum. Tried my luck.

    * Tried installing from Only 1.5 Release – 4/19/2014 (latest) available for download. Others are locked.
    * Tried installing zuul 1.5 in Tomact 7 and 8 with above instructions
    Ended up with tld issues
    org.apache.jasper.JasperException: Invalid tld file: “/WEB-INF/tags/zuul/zuul.tld”, see JSP 2.2 specification section 7.3.1 for more details

    Would be great, if Mulesoft officially supports such a solution which is of desperate need in the industry.

    • Hi everyone,
      Is there a way for ZUUL to use password encrypted by Mule property editor? Please let me know if there is a way?. I would like to avoid dependency on other encryption/decryption libraries.

    • I am currently facing the same issue.
      org.apache.jasper.JasperException: Invalid tld file: “/WEB-INF/tags/zuul/zuul.tld”, see JSP 2.2 specification section 7.3.1 for more details.
      i tried copy pasting the jasper.jar, jasper-el.jar from tomcat server libraries to the zuul application’s lib folder. But same error.
      any solutions?