The CoreOS company blog on its container-focused Linux distribution, etcd, fleet, rkt and Kubernetes tooling.
HN links it for CoreOS and container announcements and Kubernetes guidance, such as advice to use CRDs rather than TPRs; it also hosts job posts.
San Francisco, CA - CoreOS - Full Time - https://coreos.com/
__Product Marketing Manager__
Join the CoreOS team. You'll spend time with the CoreOS line of products to develop product positioning, create lead gen campaigns and develop an expertise on the overall market.
You’ll:
-Analyze the CoreOS line of products and determine the best way to price, position and market products in a competitive marketplace.
-Use a data-driven strategy based on customer insight and market research to understand how our products and solutions are doing in the marketplace.
-Create customer-facing collateral such as white papers, customer case studies, and webinars to drive prospects through the sales funnel.
-Design integrated marketing plans across owned, paid, and earned media channels - driven by a rationale for why, when, and how each channel should be used
Requirements:
-You have 5+ years of experience working for an enterprise-focused software, SaaS, or web services company.
-You have a proven track record of marketing to a highly technical audience. You are comfortable working with and marketing to developers and technical buyers within enterprises.
-You like analyzing marketing methods, doubling down on those that work and cutting those that don't.
-You have a passion for measurement, metrics and continuous improvement.
-You are hands on. Passionate. Persistent. Creative. Easy to work with. Get things done.
If interested in the product marketing position please email your…
Disclaimer: my company was acquired by Rackspace 2 years ago. I am a developer myself and below are my honest impressions (and things I have learend) of Rackspace cloud.
Back when they launched it after having had acquired Slicehost, Rackspace Cloud was the only alternative to AWS and had one significant differentiator back then: the local storage on the instances wasn't ephemeral - it was permanent. The benchmarks and pricing were competitive, so the growth was phenomenal and life was good as a result. And that's when Rackspace dropped the ball by losing some focus and getting obsessed with launching platform services one after another ignoring the compute. They even launched what I believe was the first PaaS ever and gave it an unfortunate name of "cloud sites" (and confusing plenty of developers at that point, who couldn't tell "cloud sites", significantly less powerful service, apart from "cloud servers")
As a result, for a few years the lineup of VMs they offered hasn't changed, while AWS was launching new types all the time.
So about two years ago Rackspace ended up with a great control panel (easiest cloud CP to use IMO), a comprehensive set of back-end services: block storage, object storage, MySQL-as-a-Service, email sending and receiving, MongoDB-as-a-Service, cloud deployments, CDN and many more... But the selection of virtual servers was small and the hardware was getting obsolete at that point.
Since then I've seen tremendous investments being made into the…
This guide makes an interesting choice with regards to etcd security, which I'm not sure I'd go with.
etcd stores a load of sensitive cluster information, so unauthorised access to it is a bad thing.
There's an assumption in the guide that you have a "secure network" and therefore don't have to worry about etcd authentication/encryption. The thing is if you have a compromised container (say) and that container, which has an in-cluster IP address can see your etcd server, then it can easily dump the etcd database and get access to the information held in it...
Personally I'd recommend setting up a small CA for etcd and using it's authentication features, there's a good guide to this on the CoreOS site https://coreos.com/etcd/docs/latest/op-guide/security.html
I'm working on something along these lines:
https://www.packagelab.com/
The idea is to have a common UI and REST API for building packages and managing repositories across packaging toolchains. Right now it supports rpm+yum and deb+apt. Packages are built in isolated Linux containers using Heroku's buildpack interface. (Would love feedback from anyone who's interested in beta testing.)
Also, have you seen the Omaha protocol?
https://code.google.com/p/omaha/wiki/ServerProtocol
It's used by a lot software, including Chrome and ChromeOS. Recently, CoreOS has built infrastructure with it and they offer a SaaS product for rolling updates. I think they're planning on using it to update Docker containers, too:
https://coreos.com/products/coreupdate/
A big use case of this that we are thinking about is enabling people to use the etcd Operator[1], which makes it simple to run etcd clusters on Kubernetes, to back their ZooKeeper applications.
The neat thing about the etcd Operator is you can define a cluster and the etcd Operator takes care of normal operations by using the Kubernetes API.
apiVersion: "etcd.coreos.com/v1beta1"
kind: "Cluster"
metadata:
name: "example-etcd-cluster"
spec:
size: 5
version: "3.1.8"
Pretty neat!
Anyways, the zetcd project is still super young but would love more folks to try it out. As the post says folks have already tried using Kafka, Mesos, and others.
[1] https://coreos.com/blog/introducing-the-etcd-operator.html
It depends on how you are using containers. If you control what code is run in them and who has access to the containers and their hosts, then production use should be fine as far as security goes.
However, if you're trying to run something which lets untrusted people login to the containers or run arbitrary untrusted code in the containers, then I certainly wouldn't recommend doing that with containers in a production environment.
One project you might like to keep an eye on is CoreOS [1]. As I understand it, their goal is to create an OS which will come configured to safely run containers. Once it is ready I would expect it will be suitable for use in a production environment.
[1] http://coreos.com/