\n(Metadata, DNS, Rancher compose, etc.)<\/li>\n
\ndeployment through the Rancher catalog<\/li>\n<\/ol>\n
Item 2 acts as a bridge from 1 to 3. In this article, I will go over
\neach item in more detail.<\/p>\n
Moving key Rancher features to microservices<\/h2>\n
It is well-known that monolithic systems come with certain
\ndisadvantages:<\/p>\n
- \n
- Their code bases are not easy to understand and modify<\/li>\n
- Their features are hard to test in isolation<\/li>\n
- They have longer test and release cycles.<\/li>\n<\/ul>\n
But even if your code base is pluggable and well-structured, the last
\ntwo challenges note above persist. Moving code into microservices helps
\nto overcome these challenges, and creates a lower threshold for external
\ncommitters: if you are new to open source development and willing to
\nstart contributing, smaller projects are simply easier to grasp. In
\naddition, if you look at the project pull request history for Rancher
\nExternal DNS, you might see something interesting:![\"DNS](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2016\/06\/15125536\/DNS-Providers.png\")
<\/a>
\nThe majority of commits came from people with knowledge of
\ndifferent service providers. From a contributor\u2019s point of view, having
\nand bringing in specific service provider expertise reduces the pressure
\nassociated with making initial contributions to the project. And of
\ncourse, the project benefits from getting all these provider extensions.<\/p>\nDockerizing microservices<\/h2>\n
Let\u2019s say as a contributor, you\u2019ve created this new cool
\nDNSimple provider plug-in. It was released with an external-dns service,
\nand now you want to try it in Rancher. To adopt the changes, you
\ndon\u2019t have to wait for the next Rancher release, nor do you have to
\nchange the Rancher code base. All you have to do is:<\/p>\n- \n
- fetch the last released image from the external-dns dockerhub
\nrepo<\/a><\/li>\n- create a docker-compose template with your service\u2019s deployment
\ndetails<\/li>\n<\/ul>\n![\"docker-compose\"](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2016\/06\/09155736\/docker-compose.png\")
<\/a><\/p>\n- \n
- Register your image in Rancher catalog
\nrepo<\/a> (more on how to
\ndeploy it from Rancher catalog, in the next section).<\/li>\n<\/ul>\nDeploying the service through Rancher catalog<\/h2>\n
At Rancher, we want to provide an easy way for users to describe and
\ndeploy their Docker-based applications. The Rancher catalog makes this
\npossible. By selecting an entry from the catalog, and answering several
\nquestions, you can launch your service through the Rancher platform.
\n![\"Screen](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2016\/06\/09152420\/Screen-Shot-2016-06-09-at-3.23.56-PM.png\")
<\/a>
\nAll the services are grouped by category, so it is easy to search for a
\nspecific functionality:<\/p>\n![\"grouping](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2016\/06\/09152601\/grouping-by-category.png\")
<\/a><\/h2>\nPick your newly added DNSimple service, fill in the fields and hit
\nLaunch:![\"Screen](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2016\/06\/09164213\/Screen-Shot-2016-06-09-at-4.42.00-PM.png\")
<\/a>
\nThat\u2019s it! Your service gets deployed in Rancher, and can be discovered
\nand used by any other application. The catalog enables easy upgrades for
\nmicroservices. Once the new service image is available and its template
\nis published to the catalog, Rancher will get a notification, and
\nyour service can be upgraded to the latest version in a rolling fashion.
\nThe beauty of this is that you don\u2019t have to update or upgrade Rancher
\nwhen a new version of a microservice gets released. Besides providing a
\nsimple way of defining, deploying and upgrading microservices, the
\nRancher Catalog acts as a shared template library. If you are interested
\nbuilding an Elasticsearch microservice, using GlusterFS, or dockerizing
\nDroneCI, check out their corresponding catalog items. And if you want to
\nshare your application, you can submit it to our Community catalog
\nrepo<\/a>.<\/p>\nHow microservices benefit Rancher as an orchestration platform<\/h2>\n
We\u2019ve seen the single service implementation and deployment flow; let\u2019s
\nlook at the bigger picture now. Any container orchestration platform
\nshould be easily extendable, especially when it comes to implementing a
\nspecific service provider extension. Building and deploying this
\nextension shouldn\u2019t be tightly coupled to the core platform, either.
\nMoving out the code to its own microservice repo, dockerizing the
\nservice, and allowing it to deploy it using catalog, makes everything
\neasier to maintain and support (as pictured below):![\"Rancher](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2016\/06\/15131338\/Rancher-catalog-templates-1024x526.png\")
<\/a>
\nWe are planning to move the rest of Rancher\u2019s key services to their own
\nmicroservices. This will allow users to integrate the system service
\nplugins of their choice with just a couple of clicks.<\/p>\nMoving our key services \u2013 Metadata, Internal DNS \u2013 into dockerized
\nmicroservices written in Go has helped with the release management, and
\ndriven more external commits. We\u2019ve taken things one step further and
\ndeveloped an application catalog where users can share their
\napplications\u2019 templates in docker-compose format. This has taught us
\nmore about best DevOps best practices from within our community, made us
\nmore familiar with their use cases, and helped us improve our
\nmicroservices implementations. Working on an open source project is
\nalways a two-way street \u2013 making your code easier to understand and
\nmanage helps the community contribute to and enhance the project. We
\nhave an awesome community, and appreciate every single contribution.
\nWe will continue improving contributors\u2019 experience and learning from
\nthem.<\/p>\n
- create a docker-compose template with your service\u2019s deployment
- fetch the last released image from the external-dns dockerhub