Any idea what you mean by "pay well"?I pay well.
between 150 and 250 €. as the workAny idea what you mean by "pay well"?
If you list what you will pay, that could make people say yes or no.
based on the gamecp but with an innovative / responsive designWait, I want to make this clear.
Do you want something that is based on that gameCPs(edit of thoose) or you want same features like gameCPs but made from zero?
@CubE135 yes but I wanted to edit and make a panel for my host game server and also wanted to sell that same panel to other companies for example a license generator@FusiGames Do you own a GameCP License?
Introduction
Be careful what you say, you never know what’s going to blow up — for better or worse!
I recently made this offhand comment on r/feedthebeast and was subsequently deluged with requests for a tutorial. In the spirit of contributing back to the great FTB community, I readily agreed to put together these notes.
Your goal is to host a Minecraft service that is scaled, dedicated and completely under your control; that’s fault tolerant enough to gracefully recover from most problems; minimizes admin time while running as cost effectively as possible. You can do that. Here’s how.
Overview
This series walks through all the aspects of hosting your own Minecraft world on AWS cloud services using:
EC2 to configure and run a dedicated linux Minecraft server
S3 to handle all permanent file storage
Auto Scaling to automatically bid and keep one spot EC2 instance running
SNS to publish notifications
IAM to manage and secure access to these resources
Audience
This series assumes you are:
running a local Minecraft server that you are going to transfer to AWS. Relying on a “known good” local instance of Minecraft, your modpack and world will eliminate half the guesswork later on about “why isn’t this working?”. You can always re-generate a new world once you’re up and ready to launch.
familiar with linux server administration. I assume you understand or are willing to otherwise learn concepts like ssh keys, init scripts, cron jobs, logs, and bash scripting utilities. (By the way, if you don’t know any of this, here’s a great learning opportunity with minimal risk and real tangible results once you get it working!)
willing to dive in and learn any/all of the AWS components referenced here using Amazon’s extensive documentation, examples and forums.
accepting that this is a learning experience that will cost you time and some money (but hopefully not a lot) while you experiment with what works for you.
understanding that I am just an alphageek who likes to mash stuff together. I am definitely not an AWS Cloud Giant, 10th level Initiate of the Command Line or Minecraft Modding Monk. Your mashing may result in loss of data, hours and hair. You may also see massive gaps and/or opportunities improving these works — please do contribute, but be nice about it.
Syllabus
We’re going to take a very deliberate path reaching our end goal, focusing on getting things working manually first, then automating once you’re happy with the setup.
Chapter 2 — Getting Started. Getting your AWS account setup, learning about Amazon’s server instances (EC2) and storage. Manually running your hosted Minecraft server on AWS.
Chapter 3 — Managing Minecraft [to be published]. Scripting to bootstrap, restore, start, stop and backup your Minecraft service.
Chapter 4 — Automating Deployment [to be published]. Using Auto-Scaling to bid then launch your Minecraft spot instance. Using Simple Notification Service to publish operational events.
Additional chapters may be added as needed.
---
next
---
This chapter focuses on the fundamental AWS components of your Minecraft service. Experienced AWS users can probably skim this chapter and proceed to the next one.
Amazon’s AWS documentation is fantastic so I’m just going to point you to various guides and tell you which steps to follow. We’re going to start with the Amazon EC2 Linux User Guide, which is your bible for all things EC2 and the best place to start with AWS.
Setting up your AWS Account
The Setting Up section walks you through setting up an AWS account, creating your security credentials in the Identity and Access Management service (IAM), generating keys, setting your default Virtual Private Cloud (VPC), and setting up a security group for the network.
In your security group, make sure you add a rule to allow access from all IP’s to port 25565.
In the Create an IAM User section make a Minecraft-Admins IAM group as you’ll be using this throughout the series for access control. Later, if you want to share admin duties with trusted friends, you can assign them to this group.
I used the default Virtual Private Cloud (VPC) for everything. If you know you need a custom one, set it up now.
Launching, Accessing and Terminating EC2 Instances
Follow the Getting Started section to launch, log onto and terminate your first EC2 instance. Do this a bunch of times until you’re comfortable using EC2 and the AWS Management Console.
As you get deeper into AWS it’s easy to accidentally rack up a sizable bill or to be nervous about it happening. Before going any further, you should setup a billing alert that notifies you if your monthly bill hits a specified threshold. Don’t worry about integration with SNS (Simple Notification Service), email alerts should be fine. I use >$40 for my alerts.
Launching a Spot Instance
EC2 offers spot instances where the hourly pricing is often significantly lower than standard prices. Read up on EC2 Spot Instances here and use the AWS console to bid for and launch an instance.
Once it’s up and running it acts like a regular EC2 instance in most other ways. The biggest difference is that spot instances will terminate if the spot price rises above your bid price. When that happens, the server will receive a notification and be terminated two minutes later.
Notes: Spot pricing can vary greatly depending on the machine type, region and overall demand. I had a couple of occasions where it was cheaper to run the next size larger machine or switch to a different region.
What Size Instance Should I Run?
I recommend the m3.large instance type with it’s 7.5Gb RAM and 32Gb SSD. It’s spot pricing currently hovers around $0.02/hr which translates to about $15/month if you keep it running 24x7.
Using S3 as a File Repo
All EC2 instances are ephemeral and any data stored on their local disks will be lost when the instance is terminated. For persistent storage we have a couple of options and in this case we’re going to use the easiest one: Simple Storage Service (S3).
Open the Getting Started with Amazon Simple Storage Service guide and work on creating a well-named bucket (these examples use “myftbbucket”). You’re going to treat this bucket as your master file repository for everything including your Minecraft directory, utility scripts and backups. Go ahead and create three folders at the top level of your bucket: “server”, “bin” and “backups”.
Next, you need to copy your local Minecraft server directory to the server folder in your bucket. There are many S3 tools available for you to do this. I’m a Mac guy and use a combination of AWS Command Line and Transmit. I’ll leave the choice of GUI S3 tool up to you, but you really want to install the command line at a minimum. From your local machine:
$ aws s3 cp minecraft s3://myftbbucket/server --recursive
Manually Running Minecraft
Launch an EC2 instance and ssh into it. From the command line, run the following:
$ sudo mkdir /opt/minecraft
$ sudo chown ec2-user:ec2-user /opt/minecraft
$ mkdir /opt/minecraft/server
$ cd /opt/minecraft/server
$ aws s3 cp s3://myftbbucket/server . --recursive
You should now have a copy of your Minecraft instance on your server. Use your normal startup command to test it. The default for FTB is:
$ ./ServerStart.sh
If Minecraft starts correctly, you should be able to start your client and connect to it by finding the instance’s public IP on the AWS console.
Conclusion
As much as you want to keep playing, the server you have running now isn’t very fault tolerant. Play as long as you like, but you don’t have a way to keep the server running without staying logged in via ssh, and as soon as the instance terminates you’ll lose all your data.
That’s good enough for one day though! We’ll start fixing all that tomorrow. You’ve accomplished a lot getting this far and have all the basics in place to build on going forward.