Do you, your kids, or your friends enjoy playing Minecraft on their Xbox, Windows PC, or mobile phones? If so this tutorial helps you get a Minecraft Bedrock server running reliabily on Kubernetes. Bedrock is the version which supports all platforms that aren't Java Edition¹.

Prerequisites

This quick guide uses Google Cloud Platform to spin up a small managed Kubernetes cluster on GKE to run a Minecraft Bedrock Server. I'm going to use Cloud Shell as my client which gives me the following prerequisites out of the box:

• The gcloud SDK.
• kubectl to interact with a Kubernetes cluster.

If you want to use GCP you can get started pretty quickly by cloning the gist repo with this handy link. I recommend opening it in a new tab.

Create Your Cluster

This cluster has one node (virtual machine) to run your bedrock server. If you want to deploy multiple servers, for instance one for each of your children so they don't PvP in game or IRL, you might want to change this config a little to add more nodes or change the node size.

The most important choices you'll make here are node size and zone placement.

Node Size

You can review all GCE instance pricing before committing. I'm choosing a server that, at the time of this writing, costs about $56USD/month.

Zone Placement

It's recommended you choose a zone in a region that's close to you geographically. Take a look at our locations in the docs.

Also note the CPU and Memory resource requests. The machine I chose, n2-standard-2, has 8Gb of memory available.

Deploy Minecraft Bedrock Server

Below is the configuration describing what you need to deploy the server. Let's break it down:

StorageClass

I'm using SSDs because they're faster and the name of the game, other than Minecraft, is keeping latency low. They're more expensive, so you can leave this option out if you don't want it by removing the storageClassName in the PersistentVolumeClaim configuration. Note that I'm also enabling volume expansion so when we need more space. When you want to grow space available follow (this blog post)PVC Expansion to do it.

PersistentVolumeClaim

We want server data like world generation, whitelisted users, and all the beautiful creations you've made to persist between restarts and upgrades. Here we're allocating a persistent volume for the cluster with a storage capacity of 1 Gig to start.

Deployment

We're running one replica, or instance, of the server allocating 50% of the node's memory, and around half of its CPU to the Minecraft server. You can adjust that to your needs. Also take a look at the env entries. Mojang requires the end user, you, to accept the End User License Agreement and that's available through the EULA environment variable. You set the game mode between creative, survival, and hardcore; difficulty to peaceful, easy, normal, or hard; enforce Xbox Live accounts with ONLINE_MODE, and allow cheats like /gamerule showcoordinates true for operators. All the available settings are listed in the docker container repo on GitHub.

Service

To expose this server online and make it possible for you to connect you need a service. We're using a LoadBalancer to make the server available on the typical port via UDP.

Apply this configuration to your cluster.

kubectl apply -f minecraft-bedrock-server.yaml

Configure Your Player Whitelist

By enabling the White List in the server configuration above the server is locked down. No players can access it. Let's change that by allowing only the players you choose to join. You'll need the "Gamertag" (Xbox Live username) for each player you want to give access to. Write a JSON file like the following and add the players you want on your server.

Now add the whitelist to the server. Copy the whitelist into the persistent volume claimed by the running server with the following command, then restart Minecraft.

kubectl cp whitelist.json \
  $(kubectl get pod -l app=mc-bedrock -o custom-columns=:metadata.name):/data/whitelist.json

kubectl rollout restart deployment/mc-bedrock

If you want to, you can watch the logs as the server starts up and you attempt to connect.

kubectl logs -f deployment/mc-bedrock

To connect, you'll need the IP address assigned to the Service which you can obtain by inspecting the service.

kubectl get service mc-bedrock -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Give Operator Permissions

You may want to give one or more players operator status on the server. This will let them use special commands or whitelist new players in-game. That's done with another JSON file in the form shown here.

Your "XUID" is a the unique identifier for your Xbox Live account. The best way I've managed to find this, honestly, is to view the logs when whitelisted players connect to the server. To find the XUID run the following command.

kubectl logs deployment/mc-bedrock | grep xuid

Copy the xuid you find in the log entry into your permissions.json file, upload it to persistent storage, and restart the server one more time!

kubectl cp permissions.json \
  $(kubectl get pod -l app=mc-bedrock -o custom-columns=:metadata.name):/data/permissions.json

kubectl rollout restart deployment/mc-bedrock

Backup and Restore

If you love yourself, your kids, or your friends enough you can implement VolumeSnapshots for the mc-bedrock PersistentVolumeClaim. It's more or less straight forward. Here are some docs and a blog post to get you started.

Attribution

My Kubernetes configuration was built from the work done by Geoff Bourne who maintains the canonical Docker container which makes all of this possible. Thank you, Geoff! Go follow him on Twitter, too.

I prefer values which connect us deeply over rituals and traditions only some of us are able to enjoy.

Culture fit is broken.

The words we use to describe culture matter. We talk about the rituals and traditions we enjoy together. In agile software development one of the traditions we like is standups. Some of our rituals include drinking coffee and alcohol. It's very important to us. I'm a self-described "beverage enthusiast" so I'm no stranger to these rituals. These are ways to bring some people together, but when we're creatively building something we must dig deeper to describe what we value in our collaborative interactions.

Here are some rituals and traditions that might bring us together. "She doesn't like SVN either," perhaps at an interview, convinces us she's likeminded. Do you enjoy ping pong? At Pivotal we play a lot of ping pong. I'm not excited about it, I'm not very good at it, but ping pong doesn't make me good at my job. I enjoy drinking great beer socially! Never in the history of my career has my ability to drink beer made me better at solving a business problem. I would venture a guess that's true for you, too.

That's too superficial. Let's think more deeply about the values which really bind us together when we're creative and building things.

What do you value?

Here are some values which shape the my decisions about which organizations and communities I create with.

I value blame-free failure. I value working with people who are willing to take risks, in an organization that's willing to take risks. If I can take big risks there might be big rewards, but there might also be big mistakes, and that's ok. I want to work with people who are comfortable with that. I value growth through mistakes which are, often, our best learning opportunities.

I love sharing. I like sharing success, responsibility, work, and time. Most of all I love sharing ideas, and working with people who are constantly putting their ideas out there.

I mentioned taking risks and making mistakes. I value working with people tell me how they feel about the work I've done, let me know the good and the bad, so I can grow from that. I want to provide the same for others. I value continuous learning through continuous feedback. I don't want problems to pile up on each other and become big.

I like balance. My idea of work-life balance is not the same as yours and that's ok. I have children, not everyone has children, but I can't work 16 hours a day even though I love what I do. Maybe you can and that works for you but we should try to build a culture that can support both lifestyles, and more.

These are some of things that really bind us together when we're working, they really matter. But when we're in an interview or considering what sort of community to build we tend to focus on whether or not we enjoyed coffee or had a good time at lunch. That's not really deep enough to build a strong community.

Seek value fit.

Consider how our values, the core principles of our character, fit together when building a community and working with one another. Not everyone likes coffee. Not everyone likes beer. Not every can pop off to the pub after work to make critical business decisions over a pint, so maybe we shouldn't be doing that.

This boils down to being deliberate about how we make decisions, and how we work together. Hegemony isn't an accident. If you aren't being deliberate about what values bring people in your community together then you're likely to end up with a community of people who are all the same. It's possible you will look different, or be different genders, but you're more likely to have the same experiences and lifestyles. This doesn't translate into a deeper level of inclusion.

Consider the way our values bring us together rather than the rituals and traditions we occassionally enjoy.

Seek inclusion.

Rituals and traditions are helpful but superficial ways to bring people together. Unfortunately they only bring some people together. By all means have a good time at Whiskey Friday—I will—but don't fool yourself into thinking it's an inclusive event. In fact if everyone in your organization raises a glass at Whiskey Friday you've created a culutre of rituals, not values, and that homogeneous culture is not diverse enough for me.

Thank you.

Thanks to the organizers of Ignite Velocity 2015 New York, the Pittsburgh Perl Workshop 2015, OSDC 2015, and Cloud Foundry Summit Berlin 2015 for giving me five minutes to talk about this at each of your events. I gave this talk four times in three weeks on three different continents. Recordings from Velocity and OSDC are available as are the slides.

Moving beyond ad-hoc automation to take advantage of patterns that deliver predictable capabilities.

A piece I wrote on what it means to be cloud-native.

I was honored to speak at YAPC::Asia 2015 in August. It was a well-organized conference, and the attendees and speakers were all friendly and fun.

Most of the talks I went to were English-language based. I saw excellent talks on kubernetes, docker, refactoring, golang, and lattice. Fellow Pittsburgh engineer Marylou Lenhart also spoke at the conference about posture for engineers, and I'll be trying to do my cat/cow stretches regularly.

My talk was about working remotely and working on distributed teams. It was based on my writing on durable communication. I got a lot of excellent questions after my talk and at the official dinner, and the feedback was quite positive. My slides are online and the organizing team has already posted the video:

Since I was speaking in English the conference provided live translation into Japense. It was an incredible experience. I felt like a diplomat, especially during Q&A when questions in Japanese were translated into English so I could understand them. The translators were wonderful and I'm very thankful they were available.

Finally, thank you to Daisuke Maki for inviting me to speak this year!

The mission of a DevOps team is to eliminate itself.

DevOps is a practice, not a role. It's like agility. Does your company have an agile team? From Dave Thomas's agility redux:

• You aren’t an agile programmer—you’re a programmer who programs with agility.
• You don’t work on an agile team—your team exhibits agility.
• You don’t use agile tools—you use tools that enhance your agility.

The same applies to the practice of DevOps. I suggest:

• You aren't a DevOps programmer—you're a programmer who automates deployment and operations.
• You don't work on a DevOps team—your team runs the applications you build.
• You don't use DevOps tools—you use tools that enhance your ability to ship business value.

If your company has created a dedicated "DevOps team" it signals one of two likely scenarios:

1. Things are already on fire and you're trying to catch up because you're late, or
2. You haven't realized that DevOps is a practice, like "agile", and your implementation of the concepts may be faulty.

I have built DevOps teams (responding to scenario #1, everything is on fire) and the goal of that team is always to pay the up-front investment in modernizing the software delivery pipeline. Once the investment is paid thier role is to empower engineers to run the software they create themselves, and to enable operators to avoid fires in production and get a good night's sleep. Once that equilibrium is reached it's time to move on to work which genuinely creates business value.

If your organization has a long-lived "DevOps team" and the idea is they'll always be around, how is that different from "throwing it over the wall?" In this case it's just a second wall to an intermediary team between IT and engineering, and it isn't really a good long-term strategy. It can, however, get you over the initial changes required to embrace the DevOps ideal of "you built it, you run it."

It isn't a negative that DevOps teams are created. The rationale for their existence is often quite positive, just that the implementation isn't quite as polished and inline with the intent of the DevOps movement. It should be seen as a short-term tactic and you need to have a long-term strategy. Your DevOps team will never generate business value directly, so your sustained investment isn't wise.

The reduction of cycle time is, without question, a strategic advantage. Your dedicated DevOps team can get you from waterfall to agility much faster, and reduce cycle time drastically, which is a significant improvement in the short term. As the health of your architecture improves, and isn't materially affected by modification (deployment), the value gained by sustained investment in a DevOps team goes down. This is good.

A recent report by Nancy Gohring of FierceDevOps suggests a new approach to solidifying the gap between engineering and IT: adding business people to its DevOps teams. (This reporting is not confirmed by Netflix, the company cited as its example.)

If you have a DevOps team their focus should be the reduction of operational costs over time, to the point where the [software deployment pipeline] is automated and the engineering and operations teams are well educated. A well automated pipeline enables engineering teams to bring their business value to customers: shipping. Educating both engineering and operations on how to automate and manage your architecture empowers them to do it themselves, which distributes knowledge and reduces your bus factor risk.

At this point you've achieved the success of enabling and empowering everyone in your product delivery organization to practice DevOps. Like the practice of agility, DevOps should be a consistent undertone as engineering delivers business value with low operational overhead.

Don't focus on operating your business. Focus on building it.