For any team using containers – whether in development, test, or production – an enterprise-grade registry is a non-negotiable requirement. JFrog Artifactory is much beloved by Java developers, and it’s easy to use as a Docker registry as well. To make it even easier, we’ve put together a short walkthrough to setting things up Artifactory in Rancher.
Before you start
For this article, we’ve assumed that you already have a Rancher installation up and running (if not, check out our Quick Start guide), and will be working with either Artifactory Pro or Artifactory Enterprise.
Choosing the right version of Artifactory depends on your development needs. If your main development needs include building with Maven package types, then Artifactory open source may be suitable. However, if you build using Docker, Chef Cookbooks, NuGet, PyPI, RubyGems, and other package formats then you’ll want to consider Artifactory Pro. Moreover, if you have a globally distributed development team with HA and DR needs, you’ll want to consider Artifactory Enterprise. JFrog provides a detailed matrix with the differences between the versions of Artifactory.
There’s several values you’ll need to select in order to set Artifactory up as a Docker registry, such as a public name, or public port. In this article, we refer to them as variables; just substitute the values you choose in for the variables throughout this post.
To deploy Artifactory, you’ll first need to create (or already) have a wildcard imported into Rancher for “*.$public_name”. You’ll also need to create DNS entries to the IP address for artifactory-lb, the load balancer for the Artifactory high availability architecture. Artifactory will be reached via $publish_schema://$public_name:$public_port, while the Docker registry will be reachable at $publish_schema://$docker_repo_name.$public_name:$public_port
In this blog, we’ll discuss how and why Weave developed the best-practice RED method for monitoring apps with Prometheus.
What is Prometheus Monitoring?
You may have heard a lot about Prometheus lately, especially when it comes to monitoring applications in Kubernetes. To provide a bit of background before we delve into the RED method, apps running in containers and orchestrated by Kubernetes are highly automated and dynamic, and so, when it comes to monitoring applications in these environments, traditional server-based monitoring tools designed for static services are not sufficient.
This is where Prometheus comes in.
Prometheus is an open source project that was originally developed by engineers at SoundCloud. It was built and designed specially to monitor microservices that run in containers. Data is scraped from running services at time intervals and saved to a time-series database where it can be queried via the PromQL language. Because the data is stored as a time series, it allows you to explore those time intervals to diagnose problems when they occurred and to also analyze long-term monitoring trends with your infrastructure — two awesomely powerful features of Prometheus.
At Weaveworks we built on the open source distribution of Prometheus and created a scalable, multi-tenant version that is part of our Software-as-a-Service called Weave Cloud.
After having run this service for several months now, and by using Weave Cloud to monitor itself, we’ve learned a few things about monitoring cloud native applications and devised a system that we use in determining what to measure before instrumenting code.
What to Instrument?
One of the most important decisions to make when setting up Prometheus Monitoring is deciding on the type of metrics you need to collect about your app. The metrics you choose simplifies troubleshooting when a problem occurs and also enables you to stay on top of the stability of your services and infrastructure. To help us think about what’s important to instrument, we defined a system that we call the RED method. Read more
One of the great benefits of the Rancher container management platform is that it runs on any infrastructure. While it’s possible to add any Linux machine as a host using our custom setup option, using one of the machine drivers in Rancher makes it especially easy to add and manage your infrastructure.
Today, we’re pleased to have a new machine driver available in Rancher, from our friends at cloud.ca. cloud.ca is a regional cloud IaaS for Canadian or foreign businesses requiring that all or some of their data remain in Canada, for reasons of compliance, performance, privacy or cost. The platform works as a standalone IaaS and can be combined with hybrid or multi-cloud services, allowing a mix of private cloud and other public cloud infrastructures such as Amazon Web Services. Having the cloud.ca driver available within Rancher makes it that much easier for our collective users to focus on building and running their applications, while minding data compliance requirements. Read more
Last week we announced a partnership with EVRY, one of the leading IT companies in the Nordics, to deliver Rancher’s container management platform as a service to EVRY customers. This is an exciting moment for Rancher as the service will introduce our software to a new audience looking to embrace DevOps and transform how they deliver IT.
Not surprisingly, our relationship with EVRY began last year when a couple of their cloud architects downloaded Rancher and built a small test deployment. Like so many Rancher fans, they were looking for a simple way to use containers to accelerate the adoption of DevOps and continuous delivery for customers. Read more