sig:sysadmin:projects:project18
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
sig:sysadmin:projects:project18 [2015/03/28 04:12] jgensler8 |
sig:sysadmin:projects:project18 [2021/05/02 21:36] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== Containerized Deployments and Applications (Cluster Project)====== | ||
| ====== Project Member(s) ====== | ====== Project Member(s) ====== | ||
| - | * Jeff Gensler (jgensl2@uic.edu, jgensler8@gmail.com) | + | * Chase Lee |
| ====== Purpose ====== | ====== Purpose ====== | ||
| Line 11: | Line 12: | ||
| ACM member A creates a Node.js App that needs MongoDB. If ACM member A's app becomes a hit on campus, A needs to scale the database, load balancing, etc to accommodate the new traffic. | ACM member A creates a Node.js App that needs MongoDB. If ACM member A's app becomes a hit on campus, A needs to scale the database, load balancing, etc to accommodate the new traffic. | ||
| - | ACM member B takes a Machine Learning class and decides they will use Apache Spark for analysis. B realizes that one standalone container for testing Spark is not powerful enough for the job and wishes to deploy a set of standalone containers (as opposed to YARN/Mesos on top of CoreOS) to tackle their job. | + | ACM member B takes a Machine Learning class and decides they will use Apache Spark for analysis. B realizes that one standalone container for testing Spark is not powerful enough for the job and wishes to deploy a set of standalone containers (as in, YARN or Mesos on top of CoreOS/Docker) to tackle their job. |
| ====== Resources====== | ====== Resources====== | ||
| Line 38: | Line 39: | ||
| [[https://tsuru.io/]] | [[https://tsuru.io/]] | ||
| + | |||
| + | [[https://github.com/jwilder/docker-gen]] | ||
| ====== Progress ====== | ====== Progress ====== | ||
| - | We have chosen Docker as the method of containment for such applications and CoreOS as a means of holding and scaling these containers. Typically, a user would write a systemd unit file that would typically download a docker container, name the container, and deploy it across the cluster, lettings CoreOS balance the load. While this granularity is fine for a select few, it will be too much work for someone that wants to quickly deploy their application. | + | We will be experimenting with both docker and rkt container engines. The current cluster will most likely be reinstalled. We have briefly discussed the project over the weeks via listserv and SIG meetings. I think we will be settling on a master node to orchestrate the cluster. The master node will also host a master etcd server and a kubernetes-head server. The remaining nodes will be worker nodes. |
| + | |||
| + | ===== Roadmap ===== | ||
| + | |||
| + | - Create cloud-config base for master and worker nodes. | ||
| + | * Note to account for: | ||
| + | * Bonded interface | ||
| + | * Internal DHCP server bonded interface | ||
| + | * external traffic interface | ||
| + | * Starting master etcd instance on master node for other machines to sync off of. | ||
| + | * Starting fleetctl | ||
| + | - Install Kubernetes | ||
| + | - Install Test load balancers | ||
| + | - Install whatever else... | ||
| + | |||
| + | ===== Orchestration/Deployment tools for CoreOS ===== | ||
| + | |||
| + | ** Kubernetes ** | ||
| + | |||
| + | Kubernetes is an open-source platform for automating deployment, scaling, and operations of application containers across clusters of hosts, providing container-centric infrastructure. Kubernetes is developed by Google. They have the concept of pods, which are a grouping of containers to run a given service. It seems to have a lot of support, as they are using this system on Google's Cloud Platform. | ||
| + | |||
| + | ** rkt (rock-it) ** | ||
| + | |||
| + | rkt is the next-generation container manager for Linux clusters. Actively developed from the people who develop CoreOS, rkt is designed for security, simplicity, and composability within modern cluster architectures, rkt discovers, verifies, fetches, and executes application containers with pluggable isolation. rkt can run the same container with varying degrees of protection, from lightweight, OS-level namespace and capabilities isolation to heavier, VM-level hardware virtualization. | ||
| - | ====== Orchestration/Deployment tools for CoreOS + Docker ====== | + | ===== Orchestration/Deployment tools for CoreOS + Docker (Old) ===== |
| **Deis** | **Deis** | ||
| Line 62: | Line 88: | ||
| - | ====== Orchestration/Deployment tools for Mesos + Docker ====== | + | ===== Orchestration/Deployment tools for Mesos + Docker ===== |
| **Mesosphere** | **Mesosphere** | ||
| - | For running Docker containers on Mesos. | + | We can actually deploy this on top of CoreOS. If we run a global service, fleetctl can actively maintain the number of nodes needed for a given Mesos VM. |
| **Marathon** | **Marathon** | ||
| - | This might be a suitable solution for the data scientist... | + | This is a WebUI interface for administrating the Apache Mesos Cluster. |
| - | ====== Easy deployment tools for Docker ====== | + | ===== Easy deployment tools for Docker (old) ===== |
| **Dokku OR Dokku-alt** | **Dokku OR Dokku-alt** | ||
| Line 84: | Line 110: | ||
| - | ====== Multi-Tenant ====== | + | ===== Multi-Tenant ===== |
| [[http://techs.enovance.com/7104/multi-tenant-docker-with-openstack-heat | OpenStack w/ Heat]] | [[http://techs.enovance.com/7104/multi-tenant-docker-with-openstack-heat | OpenStack w/ Heat]] | ||
sig/sysadmin/projects/project18.1427515965.txt.gz · Last modified: 2021/05/02 21:36 (external edit)
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
