Separation of concerns assigns distinct responsibilities to separate components, reducing the amount of code you must reason about when adding features or fixing bugs. section 5.6
A worker API illustrates the pattern: the API receives requests, handlers translate them into queue operations, and the worker starts or stops tasks. Each responsibility has a clear home. section 5.6
In an orchestration system, separate administrative concerns from execution concerns:
- Let the manager handle user requests, scheduling, task and worker state, and failed-task restarts. section 7.1
- Let workers perform the operations that execute tasks. section 7.1
- Treat the control plane as the decision-making layer and the data plane as the layer that performs the work. section 7.1
Starting and stopping a container task
Run the worker loop separately from the API. A POST request adds a task to the queue; the worker later starts its container. A DELETE request queues a stop operation; the worker stops and removes the container. GET /tasks reports the resulting state. section 5.6
Listing 5.9 Running our worker from main.go
func main() {
host := os.Getenv("CUBE_HOST")
port, _ := strconv.Atoi(os.Getenv("CUBE_PORT"))
fmt.Println("Starting Cube worker")
w := worker.Worker{
Queue: *queue.New(),
Db: make(map[uuid.UUID]*task.Task),
}
api := worker.Api{Address: host, Port: port, Worker: &w}
go runTasks(&w)
api.Start()
}
The minimal Go entry point makes the boundaries explicit: construct a worker, construct an API around it, run task processing separately, and start the API. section 5.6
