booktitle={Proceedings of the 5th {International}{Conference} on {Computer}{Supported}{Education}},
publisher={SciTePress - Science and and Technology Publications},
author={Totschnig, Michael and Willems, Christian and Meinel, Christoph},
year={2013},
pages={593--598},
file={2013 - openHPI Evolution of a MOOC Platform from LMS to .pdf:/home/chris/Zotero/storage/UBWTRJJ7/2013 - openHPI Evolution of a MOOC Platform from LMS to .pdf:application/pdf},
title={{CodeOcean} and {CodeHarbor}: {Auto}-{Grader} and {Code}{Repository}},
abstract={The Hasso Plattner Institute (HPI) successfully operates a MOOC (Massive Open Online Course) platform since 2012. Since 2013, global enterprises, international organizations, governments, and research projects funded by the German ministry of education are partnering with us to operate their own instances of the platform. The focus of our platform instance is on IT topics, which includes programming courses in different programming languages. An important element of these courses are graded hands-on programming assignments. MOOCs, even more than traditional classroom situations, depend on automated solutions to assess programming exercises. Manual evaluation is not an option due to the massive amount of users that participate in these courses. The paper at hand presents two of the tools developed in this context at the HPI: CodeOcean—an auto-grader for a variety of programming languages, and CodeHarbor, a tool to share auto-gradable programming exercises between various online platforms.},
abstract={submit50 is a command-line tool with which you can submit work (e.g., problem sets) to a course (e.g., CS50). It’s based on git, a “distributed version control system” that allows you to save diffe...},
language={en},
journal={Seventh SPLICE Workshop at SIGCSE 2021 “CS Education Infrastructure for All III: From Ideas to Practice (SPLICE'21)},
author={Serth, Sebastian and Staubitz, Thomas and Teusner, Ralf and Meinel, Christoph},
year={2021},
file={Serth et al. - CodeOcean and CodeHarbor Auto-Grader and Code Rep.pdf:/home/chris/Zotero/storage/ECQHYIQ8/Serth et al. - CodeOcean and CodeHarbor Auto-Grader and Code Rep.pdf:application/pdf},
abstract={submit50 is a command-line tool with which you can submit work (e.g., problem sets) to a course (e.g., CS50). It’s based on git, a “distributed version control system” that allows you to save diffe...},
@article{serth_codeocean_2021,
title={{CodeOcean} and {CodeHarbor}: {Auto}-{Grader} and {Code}{Repository}},
abstract={The Hasso Plattner Institute (HPI) successfully operates a MOOC (Massive Open Online Course) platform since 2012. Since 2013, global enterprises, international organizations, governments, and research projects funded by the German ministry of education are partnering with us to operate their own instances of the platform. The focus of our platform instance is on IT topics, which includes programming courses in different programming languages. An important element of these courses are graded hands-on programming assignments. MOOCs, even more than traditional classroom situations, depend on automated solutions to assess programming exercises. Manual evaluation is not an option due to the massive amount of users that participate in these courses. The paper at hand presents two of the tools developed in this context at the HPI: CodeOcean—an auto-grader for a variety of programming languages, and CodeHarbor, a tool to share auto-gradable programming exercises between various online platforms.},
language={en},
urldate={2024-08-25},
journal={Seventh SPLICE Workshop at SIGCSE 2021 “CS Education Infrastructure for All III: From Ideas to Practice (SPLICE'21)},
author={Serth, Sebastian and Staubitz, Thomas and Teusner, Ralf and Meinel, Christoph},
year={2021},
file={Serth et al. - CodeOcean and CodeHarbor Auto-Grader and Code Rep.pdf:/Users/chris/Zotero/storage/ECQHYIQ8/Serth et al. - CodeOcean and CodeHarbor Auto-Grader and Code Rep.pdf:application/pdf},
booktitle={Proceedings of the 5th {International}{Conference} on {Computer}{Supported}{Education}},
publisher={SciTePress - Science and and Technology Publications},
author={Totschnig, Michael and Willems, Christian and Meinel, Christoph},
year={2013},
pages={593--598},
file={2013 - openHPI Evolution of a MOOC Platform from LMS to .pdf:/Users/chris/Zotero/storage/UBWTRJJ7/2013 - openHPI Evolution of a MOOC Platform from LMS to .pdf:application/pdf},
title={Tutor: the {Docker}-based {Open}{edX} distribution designed for peace of mind — {Tutor} documentation},
url={https://docs.tutor.edly.io/},
urldate={2024-09-20},
file={Tutor\: the Docker-based Open edX distribution designed for peace of mind — Tutor documentation:/Users/chris/Zotero/storage/LDFYGRBX/docs.tutor.edly.io.html:text/html},
@ -15,6 +15,7 @@ In particular, this project aims to provide the following benefits to Open edX o
* Scalable hosting for instances of any size. This means for example that the default configuration includes autoscaling of LMS pods to handle increased traffic.
* Flexibility: this project aims to be "batteries included" and to support setting up all the resources that you need, with useful default configurations, but it is carefully designed so that operators can configure, replace, or disable any components as needed.
Kubernetes und Nomad sind beides Plattformen für das Management und die Orchestrierung von Containern, aber sie haben unterschiedliche Konzepte und Architekturen. Um die beiden Systeme zu vergleichen, insbesondere in Bezug auf Begriffe wie Deployment, Job, Pod, und deren Umsetzung in beiden Systemen, ist es wichtig, die jeweilige Architektur und Konzepte im Detail zu verstehen.
=== 1. Grundlegende Architektur
=== Grundlegende Architektur ===
- **Kubernetes** besteht aus einem Master-Node (Control Plane) und mehreren Worker-Nodes. Der Master-Node übernimmt die Steuerung, Scheduling, und Verwaltung der Clusterressourcen. Die Worker-Nodes führen die Container (Pods) aus.
- **Nomad** hat eine zentrale Architektur, bei der ein Nomad-Cluster aus Servern und Clients besteht. Die Server verwalten den Zustand und die Planung von Jobs, während die Clients die Jobs tatsächlich ausführen. Nomad ist etwas flexibler, da es nicht nur Container, sondern auch andere Arten von Workloads (z. B. Nicht-Container-Anwendungen, Batch-Jobs) orchestrieren kann.
=== 2. **Vergleich wichtiger Konzepte**
=== Vergleich wichtiger Konzepte ===
[cols="^3a,a,a", frame="none"]
[cols="^a,2a,2a", frame="none"]
|===
| Konzept | Kubernetes | Nomad
@ -27,7 +27,7 @@ Kubernetes und Nomad sind beides Plattformen für das Management und die Orchest
| **StatefulSet**| Kubernetes verwendet StatefulSets für zustandsbehaftete Anwendungen, die individuelle, persistente Speicher benötigen und geordnete Starts und Beendigungen erfordern. | Nomad unterstützt Stateful-Anwendungen durch die Verwendung von Volumes und Persistent Data. Es gibt jedoch keine direkte Entsprechung zum StatefulSet von Kubernetes.
|===
=== 3. **Entsprechungen für eine Nomad-zu-Kubernetes-Umsetzung**
=== Entsprechungen für eine Nomad-zu-Kubernetes-Umsetzung ===
Wenn du eine **Nomad-Job-Definition** in eine Kubernetes-Umgebung umschreiben möchtest, sind folgende Konzepte besonders relevant:
@ -44,7 +44,7 @@ Wenn du eine **Nomad-Job-Definition** in eine Kubernetes-Umgebung umschreiben m
- **Task-Gruppen in Nomad -> Kubernetes Pods**
- In Nomad gibt es "Task Groups", die eine Gruppe von Tasks innerhalb eines Jobs darstellen, die zusammen bereitgestellt werden. Das ist vergleichbar mit Kubernetes Pods, die mehrere Container enthalten.
### 4. **Spezielle Deployment-Szenarien**
=== Spezielle Deployment-Szenarien ===
- **Stateful Anwendungen**:
- In Kubernetes verwendet man StatefulSets, um zustandsbehaftete Anwendungen zu deployen, während Nomad hier mit individuellen Jobs und Persistent Volumes arbeitet.
@ -52,7 +52,7 @@ Wenn du eine **Nomad-Job-Definition** in eine Kubernetes-Umgebung umschreiben m
- **Service Mesh und Service Discovery**:
- Kubernetes verwendet standardmäßig Services und optional zusätzliche Service-Mesh-Lösungen wie Istio, um Netzwerktraffic zu steuern. Nomad verwendet oft Consul für Service Discovery und kann in ein Service-Mesh integriert werden.
=== 5. **Beispiel: Nomad-Job zu Kubernetes Deployment**
=== Beispiel: Nomad-Job zu Kubernetes Deployment ===
#### Nomad Job Definition:
```hcl
@ -76,7 +76,7 @@ job "example" {
}
```
#### Entsprechendes Kubernetes Deployment:
==== Entsprechendes Kubernetes Deployment: ====
```yaml
apiVersion: apps/v1
kind: Deployment
@ -103,7 +103,7 @@ spec:
memory: "256Mi"
```
=== Wichtige Unterschiede und Gemeinsamkeiten für die Umsetzung
=== Wichtige Unterschiede und Gemeinsamkeiten für die Umsetzung ===
- **Pods in Kubernetes** entsprechen **Task Groups in Nomad**, mit jedem Task in Nomad, der einem Container in Kubernetes entspricht.
- **Nomad Jobs** sind flexibler und können sowohl Batch-Prozesse als auch Services umfassen, während in Kubernetes Batch-Jobs von Deployments (für kontinuierlich laufende Dienste) unterschieden werden.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Christoph Walther