Replicated With Less Privileges
When deploying a secure system it is important to ensure that each component only has access to the lowest level of privileges needed to perform its task. This concept should apply to any access in a system, including the user account and file system permissions need to spawn processes successfully.
Replicated runs in Docker containers on the host server(s). Docker currently requires root (or root-equivalent) to run. But Replicated doesn’t require root privileges to perform most tasks.
Custom Preflight Checks
Out of the box, Replicated always runs a set of preflight checks when your application is first installed or when any update is being installed. We check to make sure the server(s) and the environment running Replicated meets our minimum requirements and we offer some options to configure this to allow application developers the control to adjust the values we check for.
In Replicated 2.5.0, any application distributed on Replicated can now include additional custom preflight checks.
Replicated Automatic Updates
We’ve recently shipped one of the most requested features in Replicated: the ability for Replicated to self-update! This isn’t enabled by default; read more about how the feature works and how to use it.
Replicated Release Schedule Before jumping into how to implement this feature, we should discuss the planned and expected Replicated release schedule. Replicated supports the standard semver specification. We ship a minor version monthly. Our minor versions contain new functionality, but does not break backward compatibility.
Changing the Enterprise Software Narrative
Today we launched EnterpriseReady. Our goal with this project is to change the enterprise narrative from “how to SELL to the enterprise” to “how to BUILD for the enterprise”. But what does that mean exactly?
From our perspective, too much of the conversation about enterprise software has been dominated with advice about to sell & market to enterprise buyers. This advice is full of tips and tricks about how to manage the different players in the buying process.
First Look at Docker SwarmKit
I was planning to deploy a test environment for a new application today, then the release of Docker SwarmKit came. I saw this as the perfect opportunity to spend part of the day giving SwarmKit a try. This post is a very early look at my experience installing SwarmKit on EC2 servers.
At Replicated we write a platform which allows SaaS companies (including several dev tools) to deploy into private environments by using Docker.
Management Console Settings Screen
The installable components of Replicated that your customers interact with are now more configurable with the introduction of the Management Console Settings screen. The layout is similar to the customizable configuration screen that allows each of your customers to configure their instance of your application. It will also reflect any [custom branding]*https://blog.replicated.com/2015/12/02/custom-branding/() that you’ve added.
This page is linked from the gear in the upper right corner, but is always available at :8800/console/settings.
Airgapped Installation Support
Replicated now supports three types of installation: direct connect, proxy and today we’re introducing air gapped installation. “Air gapped” basically means a server or network that is physically isolated and does not have outbound or inbound internet access. By default, Replicated installed applications require access to an outbound internet connection to check for updates & sync license information. Air gapped installations ensure that this is no longer a requirement. Instead of reaching out to our remote endpoint for installations and updates, we check a local file path.
Bypass TLS Security Warning Instructions
Replicated now serves a static page over HTTP on port 8800 to provide browser specific instructions for bypassing TLS warnings about the self-signed certs used to bootstrap the server. Specifically, Chrome, Firefox, Internet Explorer and Safari are detected with bypass instructions. Instructions are also provided to verify the fingerprint of the self-signed cert.
Your customers can bypass the security warning completely by setting the hostname and file paths of the key and cert by using the CLI commands and then visiting the hostname on port 8800 over HTTPS.
By default each instance is now verified against the standard [Replicated Preflight Checks)(http://docs.replicated.com/docs/preflight-checks) during the installation and update processes. The goal of this feature is to surface potential issues to the end user before they become support tickets for Replicated application vendors. The check is run immediately after the .rli file is uploaded by the customer and immediately before an update is applied. SaaS vendors can provide custom preflight checks in their application YAML if their application has specific requirements around network, memory, storage etc.
For the past year or so, we’ve been deploying Docker containers behind the firewall and have watched Docker change and mature a lot. The ecosystem has moved crazy-fast to produce a lot of good ideas about what makes a great Dockerfile. But there’s a lot to ingest and the art of crafting a Dockerfile is still young. So, we’ve decided to write and open source a tool to help statically analyze a Dockerfile and alert you to some best practices, optimizations and possible bugs.