4 Workers of the Cube, unite!

 

This chapter covers

  • Reviewing the purpose of the worker component in an orchestration system
  • Reviewing the Task and Docker structs
  • Defining and implementing an algorithm for processing incoming tasks
  • Building a simple state machine to transition tasks between states
  • Implementing the worker’s methods for starting and stopping tasks

Think about running a web server that serves static pages. In many cases, running a single instance of our web server on a single physical or virtual machine is good enough. As the site grows in popularity, however, this setup poses several problems:

  • Resource availability—Given the other processes running on the machine, is there enough memory, CPU, and disk space to meet the needs of our web server?
  • Resilience—If the machine running the web server goes down, our site goes down with it.

Running multiple instances of our web server helps us solve these problems.

In this chapter, we will focus on fleshing out the Worker skeleton sketched out in chapter 2. It will use the Task implementation we covered in chapter 3. At the end of the chapter, we’ll use our implementation of the worker to run multiple instances of a simple web server like that in our previously described scenario.

4.1 The Cube worker

4.2 Tasks and Docker

4.3 The role of the queue

4.4 The role of the DB

4.5 Counting tasks

4.6 Implementing the worker’s methods

4.6.1 Implementing the StopTask method

4.6.2 Implementing the StartTask method

4.6.3 An interlude on task state

4.6.4 Implementing the RunTask method

4.7 Putting it all together

sitemap