feat(docs): Restructure entire documentation
This commit is contained in:
parent
880c0d5ec9
commit
41e3306942
GPG key ID:
7C4D0F375BCEE533
50 changed files with 560 additions and 1557 deletions
|
|
@ -1,39 +0,0 @@
|
|||
---
|
||||
title: "Components"
|
||||
linkTitle: "Components"
|
||||
weight: 30
|
||||
description: >
|
||||
Overview of EDP platform components and their integration.
|
||||
---
|
||||
|
||||
{{% alert title="Draft" color="warning" %}}
|
||||
**Editorial Status**: This page is currently being developed.
|
||||
|
||||
* **Jira Ticket**: [TICKET-XXX](https://your-jira/browse/TICKET-XXX)
|
||||
* **Assignee**: Stephan
|
||||
* **Status**: Draft
|
||||
* **Last Updated**: YYYY-MM-DD
|
||||
* **TODO**:
|
||||
* [ ] Add detailed component description
|
||||
* [ ] Include usage examples and code samples
|
||||
* [ ] Add architecture diagrams
|
||||
* [ ] Review and finalize content
|
||||
{{% /alert %}}
|
||||
|
||||
This section documents all components of the Edge Developer Platform based on the product structure.
|
||||
|
||||
## Component Categories
|
||||
|
||||
The EDP consists of the following main component categories:
|
||||
|
||||
* **Orchestrator**: Platform and infrastructure orchestration
|
||||
* **Forgejo & CI/CD**: Source code management and automation
|
||||
* **Deployments**: Deployment targets and edge connectivity
|
||||
* **Dev Environments**: Development environment provisioning
|
||||
* **Physical Environments**: Runtime infrastructure
|
||||
|
||||
### Product Component Structure
|
||||
|
||||
[TODO] Links
|
||||
|
||||
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
---
|
||||
title: "Documentation System"
|
||||
linkTitle: "Documentation System"
|
||||
weight: 100
|
||||
description: The developer 'documentation as code' documentation System we use ourselfes and over to use for each development team.
|
||||
---
|
||||
|
||||
{{% alert title="Draft" color="warning" %}}
|
||||
**Editorial Status**: This page is currently being developed.
|
||||
|
||||
* **Jira Ticket**: [TICKET-6736](https://jira.telekom-mms.com/browse/IPCEICIS-6736)
|
||||
* **Assignee**: Stephan
|
||||
* **Status**: Draft
|
||||
* **Last Updated**: YYYY-MM-DD
|
||||
* **TODO**:
|
||||
* [ ] Add detailed component description
|
||||
* [ ] Include usage examples and code samples
|
||||
* [ ] Add architecture diagrams
|
||||
* [ ] Review and finalize content
|
||||
{{% /alert %}}
|
||||
|
||||
The Orchestration manages platform and infrastructure provisioning, providing the foundation for the EDP deployment model.
|
||||
|
||||
## Sub-Components
|
||||
|
||||
* **Infrastructure Provisioning**: Low-level infrastructure deployment (infra-deploy, infra-catalogue)
|
||||
* **Platform Provisioning**: Platform-level component deployment via Stacks
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
---
|
||||
title: "Forgejo Actions"
|
||||
linkTitle: "Forgejo Actions"
|
||||
weight: 20
|
||||
description: Forgejo Actions.
|
||||
---
|
||||
|
||||
{{% alert title="Draft" color="warning" %}}
|
||||
**Editorial Status**: This page is currently being developed.
|
||||
|
||||
* **Jira Ticket**: [TICKET-6730](https://jira.telekom-mms.com/browse/IPCEICIS-6730)
|
||||
* **Assignee**: [Name or Team]
|
||||
* **Status**: Draft
|
||||
* **Last Updated**: YYYY-MM-DD
|
||||
* **TODO**:
|
||||
* [ ] Add detailed component description
|
||||
* [ ] Include usage examples and code samples
|
||||
* [ ] Add architecture diagrams
|
||||
* [ ] Review and finalize content
|
||||
{{% /alert %}}
|
||||
|
||||
Forgejo provides source code management, project management, and CI/CD automation for the EDP.
|
||||
|
||||
## Sub-Components
|
||||
|
||||
* **Project Management**: Issue tracking and project management features
|
||||
* **Actions**: CI/CD automation (see CI/CD section)
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
---
|
||||
title: Environments
|
||||
linkTitle: Environments
|
||||
weight: 40
|
||||
description: >
|
||||
Deployment targets and edge connectivity solutions.
|
||||
---
|
||||
|
||||
{{% alert title="Draft" color="warning" %}}
|
||||
**Editorial Status**: This page is currently being developed.
|
||||
|
||||
* **Jira Ticket**: [TICKET-6733](https://jira.telekom-mms.com/browse/IPCEICIS-6733)
|
||||
* **Assignee**: Patrick
|
||||
* **Status**: Draft
|
||||
* **Last Updated**: YYYY-MM-DD
|
||||
* **TODO**:
|
||||
* [ ] Add detailed component description
|
||||
* [ ] Include usage examples and code samples
|
||||
* [ ] Add architecture diagrams
|
||||
* [ ] Review and finalize content
|
||||
{{% /alert %}}
|
||||
|
||||
Deployment components manage connections to various deployment targets including cloud infrastructure and edge devices.
|
||||
|
||||
## Components
|
||||
|
||||
* **OTC**: Open Telekom Cloud deployment target
|
||||
* **EdgeConnect**: Secure edge connectivity solution
|
||||
|
|
@ -1,128 +0,0 @@
|
|||
---
|
||||
title: "OTC (Open Telekom Cloud)"
|
||||
linkTitle: "OTC"
|
||||
weight: 10
|
||||
description: >
|
||||
Open Telekom Cloud deployment and infrastructure target
|
||||
---
|
||||
|
||||
{{% alert title="Draft" color="warning" %}}
|
||||
**Editorial Status**: This page is currently being developed.
|
||||
|
||||
* **Jira Ticket**: [TICKET-6733](https://jira.telekom-mms.com/browse/IPCEICIS-6733)
|
||||
* **Assignee**: Patrick
|
||||
* **Status**: Draft
|
||||
* **Last Updated**: YYYY-MM-DD
|
||||
* **TODO**:
|
||||
* [ ] Add detailed component description
|
||||
* [ ] Include usage examples and code samples
|
||||
* [ ] Add architecture diagrams
|
||||
* [ ] Review and finalize content
|
||||
{{% /alert %}}
|
||||
|
||||
## Overview
|
||||
|
||||
[Detailed description of the component - what it is, what it does, and why it exists]
|
||||
|
||||
## Key Features
|
||||
|
||||
* [Feature 1]
|
||||
* [Feature 2]
|
||||
* [Feature 3]
|
||||
|
||||
## Purpose in EDP
|
||||
|
||||
[Explain the role this component plays in the Edge Developer Platform and how it contributes to the overall platform capabilities]
|
||||
|
||||
## Repository
|
||||
|
||||
**Code**: [Link to source code repository]
|
||||
|
||||
**Documentation**: [Link to component-specific documentation]
|
||||
|
||||
## Getting Started
|
||||
|
||||
### Prerequisites
|
||||
|
||||
* [Prerequisite 1]
|
||||
* [Prerequisite 2]
|
||||
|
||||
### Quick Start
|
||||
|
||||
[Step-by-step guide to get started with this component]
|
||||
|
||||
1. [Step 1]
|
||||
2. [Step 2]
|
||||
3. [Step 3]
|
||||
|
||||
### Verification
|
||||
|
||||
[How to verify the component is working correctly]
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### [Use Case 1]
|
||||
|
||||
[Example with code/commands showing common use case]
|
||||
|
||||
```bash
|
||||
# Example commands
|
||||
```
|
||||
|
||||
### [Use Case 2]
|
||||
|
||||
[Another common scenario]
|
||||
|
||||
## Integration Points
|
||||
|
||||
* **[Component A]**: [How it integrates]
|
||||
* **[Component B]**: [How it integrates]
|
||||
* **[Component C]**: [How it integrates]
|
||||
|
||||
## Architecture
|
||||
|
||||
[Optional: Add architectural diagrams and descriptions]
|
||||
|
||||
### Component Architecture (C4)
|
||||
|
||||
[Add C4 Container or Component diagrams showing the internal structure]
|
||||
|
||||
### Sequence Diagrams
|
||||
|
||||
[Add sequence diagrams showing key interaction flows with other components]
|
||||
|
||||
### Deployment Architecture
|
||||
|
||||
[Add infrastructure and deployment diagrams showing how the component is deployed]
|
||||
|
||||
## Configuration
|
||||
|
||||
[Key configuration options and how to set them]
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### [Common Issue 1]
|
||||
|
||||
**Problem**: [Description]
|
||||
|
||||
**Solution**: [How to fix]
|
||||
|
||||
### [Common Issue 2]
|
||||
|
||||
**Problem**: [Description]
|
||||
|
||||
**Solution**: [How to fix]
|
||||
|
||||
## Status
|
||||
|
||||
**Maturity**: [Production / Beta / Experimental]
|
||||
|
||||
## Additional Resources
|
||||
|
||||
* [Link to external documentation]
|
||||
* [Link to community resources]
|
||||
* [Link to related components]
|
||||
|
||||
## Documentation Notes
|
||||
|
||||
[Instructions for team members filling in this documentation - remove this section once complete]
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
---
|
||||
title: "Physical Environments"
|
||||
linkTitle: "Physical Envs"
|
||||
weight: 60
|
||||
description: >
|
||||
Physical runtime environments and infrastructure providers.
|
||||
---
|
||||
|
||||
Physical environment components provide the runtime infrastructure for deploying and running applications.
|
||||
|
||||
## Components
|
||||
|
||||
* **Docker**: Container runtime
|
||||
* **Kubernetes**: Container orchestration
|
||||
* **LXC**: Linux Containers
|
||||
* **Provider**: Infrastructure provider abstraction
|
||||
|
|
@ -1,869 +0,0 @@
|
|||
---
|
||||
title: "Docker"
|
||||
linkTitle: "Docker"
|
||||
weight: 10
|
||||
description: >
|
||||
Container runtime for running containerized applications
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Docker is a container platform that packages applications and dependencies into standardized units called containers. In the Edge Developer Platform, Docker serves three primary functions: powering local development environments through Docker Desktop, building container images in CI/CD pipelines, and providing Docker-in-Docker (DinD) execution environments for Forgejo Actions runners.
|
||||
|
||||
Docker provides a consistent runtime environment across development, testing, and production, ensuring applications behave identically regardless of the underlying infrastructure.
|
||||
|
||||
## Key Features
|
||||
|
||||
* **Container Runtime**: Execute isolated application containers with process, network, and filesystem isolation
|
||||
* **Image Building**: Create container images using Dockerfile specifications and layer caching
|
||||
* **Docker-in-Docker**: Nested Docker execution for CI/CD runners and containerized build environments
|
||||
* **Multi-stage Builds**: Optimize image size through efficient build processes
|
||||
* **Volume Management**: Persistent data storage with bind mounts and named volumes
|
||||
* **Network Isolation**: Software-defined networking with bridge, host, and overlay networks
|
||||
* **Resource Control**: CPU, memory, and I/O limits through Linux cgroups
|
||||
|
||||
## Purpose in EDP
|
||||
|
||||
Docker plays several critical roles in the Edge Developer Platform:
|
||||
|
||||
**Local Development**: Docker Desktop provides developers with containerized development environments, enabling consistent tooling and dependencies across different machines. Developers can run entire application stacks locally using docker-compose configurations.
|
||||
|
||||
**Image Building**: CI/CD pipelines use Docker to build container images from source code. The `docker build` command transforms Dockerfiles into layered images that can be deployed to Kubernetes or other container orchestration platforms.
|
||||
|
||||
**CI/CD Execution**: Forgejo Actions runners use Docker-in-Docker to execute workflow steps in isolated containers. Each job runs in a fresh container environment, ensuring clean state and reproducible builds.
|
||||
|
||||
## Repository
|
||||
|
||||
**Code**: Docker is an open-source project
|
||||
|
||||
**Documentation**:
|
||||
* [Docker Official Documentation](https://docs.docker.com/)
|
||||
* [Containerd Documentation](https://containerd.io/docs/)
|
||||
* [OCI Runtime Specification](https://github.com/opencontainers/runtime-spec)
|
||||
* [OverlayFS Documentation](https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html)
|
||||
|
||||
## Getting Started
|
||||
|
||||
### Prerequisites
|
||||
|
||||
* Linux kernel 3.10+ with namespace and cgroup support
|
||||
* 64-bit processor architecture (x86_64, ARM64)
|
||||
* At least 4GB RAM for Docker Desktop
|
||||
* 20GB available disk space for images and containers
|
||||
|
||||
### Quick Start
|
||||
|
||||
**Install Docker on Linux**:
|
||||
|
||||
```bash
|
||||
# Install Docker using official script
|
||||
curl -fsSL https://get.docker.com -o get-docker.sh
|
||||
sudo sh get-docker.sh
|
||||
|
||||
# Add user to docker group (optional, allows running docker without sudo)
|
||||
sudo usermod -aG docker $USER
|
||||
|
||||
# Start Docker daemon
|
||||
sudo systemctl start docker
|
||||
sudo systemctl enable docker
|
||||
```
|
||||
|
||||
**Install Docker Desktop** (macOS/Windows):
|
||||
|
||||
1. Download Docker Desktop from [docker.com](https://www.docker.com/products/docker-desktop)
|
||||
2. Run the installer
|
||||
3. Launch Docker Desktop from Applications
|
||||
4. Verify installation in system tray/menu bar
|
||||
|
||||
### Verification
|
||||
|
||||
Verify Docker installation:
|
||||
|
||||
```bash
|
||||
# Check Docker version
|
||||
docker --version
|
||||
|
||||
# Verify daemon is running
|
||||
docker info
|
||||
|
||||
# Run test container
|
||||
docker run hello-world
|
||||
|
||||
# Check running containers
|
||||
docker ps
|
||||
|
||||
# View all containers (including stopped)
|
||||
docker ps -a
|
||||
|
||||
# List downloaded images
|
||||
docker images
|
||||
```
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### Running Containers
|
||||
|
||||
**Basic Container Execution**:
|
||||
|
||||
```bash
|
||||
# Run container in foreground
|
||||
docker run ubuntu:22.04 echo "Hello from container"
|
||||
|
||||
# Run container in background (detached)
|
||||
docker run -d --name nginx-server nginx:latest
|
||||
|
||||
# Run interactive container with shell
|
||||
docker run -it ubuntu:22.04 /bin/bash
|
||||
|
||||
# Run container with port mapping
|
||||
docker run -d -p 8080:80 nginx:latest
|
||||
|
||||
# Run container with volume mount
|
||||
docker run -d -v /host/data:/container/data ubuntu:22.04
|
||||
|
||||
# Run container with environment variables
|
||||
docker run -d -e POSTGRES_PASSWORD=secret postgres:15
|
||||
|
||||
# Run container with resource limits
|
||||
docker run -d --memory=512m --cpus=1.5 nginx:latest
|
||||
```
|
||||
|
||||
**Container Management**:
|
||||
|
||||
```bash
|
||||
# Stop container
|
||||
docker stop nginx-server
|
||||
|
||||
# Start stopped container
|
||||
docker start nginx-server
|
||||
|
||||
# Restart container
|
||||
docker restart nginx-server
|
||||
|
||||
# View container logs
|
||||
docker logs nginx-server
|
||||
docker logs -f nginx-server # Follow logs
|
||||
|
||||
# Execute command in running container
|
||||
docker exec -it nginx-server /bin/bash
|
||||
|
||||
# Copy files between host and container
|
||||
docker cp myfile.txt nginx-server:/tmp/
|
||||
docker cp nginx-server:/tmp/myfile.txt ./
|
||||
|
||||
# Inspect container details
|
||||
docker inspect nginx-server
|
||||
|
||||
# View container resource usage
|
||||
docker stats nginx-server
|
||||
|
||||
# Remove container
|
||||
docker rm nginx-server
|
||||
docker rm -f nginx-server # Force remove running container
|
||||
```
|
||||
|
||||
### Building Images
|
||||
|
||||
**Simple Dockerfile**:
|
||||
|
||||
```dockerfile
|
||||
# Dockerfile
|
||||
FROM ubuntu:22.04
|
||||
|
||||
# Install dependencies
|
||||
RUN apt-get update && apt-get install -y \
|
||||
curl \
|
||||
vim \
|
||||
&& rm -rf /var/lib/apt/lists/*
|
||||
|
||||
# Set working directory
|
||||
WORKDIR /app
|
||||
|
||||
# Copy application files
|
||||
COPY . /app
|
||||
|
||||
# Set environment variable
|
||||
ENV APP_ENV=production
|
||||
|
||||
# Expose port
|
||||
EXPOSE 8080
|
||||
|
||||
# Define entrypoint
|
||||
CMD ["./start.sh"]
|
||||
```
|
||||
|
||||
**Build and Tag Image**:
|
||||
|
||||
```bash
|
||||
# Build image from Dockerfile
|
||||
docker build -t myapp:1.0 .
|
||||
|
||||
# Build with build arguments
|
||||
docker build --build-arg VERSION=1.0 -t myapp:1.0 .
|
||||
|
||||
# Build without cache
|
||||
docker build --no-cache -t myapp:1.0 .
|
||||
|
||||
# Tag image for registry
|
||||
docker tag myapp:1.0 registry.example.com/myapp:1.0
|
||||
|
||||
# Push to registry
|
||||
docker push registry.example.com/myapp:1.0
|
||||
|
||||
# Pull from registry
|
||||
docker pull registry.example.com/myapp:1.0
|
||||
```
|
||||
|
||||
**Multi-stage Build**:
|
||||
|
||||
```dockerfile
|
||||
# Dockerfile with multi-stage build
|
||||
FROM golang:1.21 AS builder
|
||||
|
||||
WORKDIR /src
|
||||
COPY go.mod go.sum ./
|
||||
RUN go mod download
|
||||
|
||||
COPY . .
|
||||
RUN CGO_ENABLED=0 go build -o /app/server
|
||||
|
||||
# Final stage
|
||||
FROM alpine:3.19
|
||||
|
||||
RUN apk --no-cache add ca-certificates
|
||||
COPY --from=builder /app/server /usr/local/bin/server
|
||||
|
||||
USER nobody
|
||||
EXPOSE 8080
|
||||
CMD ["server"]
|
||||
```
|
||||
|
||||
Multi-stage builds reduce final image size by excluding build tools and intermediate artifacts.
|
||||
|
||||
### Docker-in-Docker for CI/CD
|
||||
|
||||
**DinD Container for Building Images**:
|
||||
|
||||
```bash
|
||||
# Start DinD daemon
|
||||
docker run -d \
|
||||
--name dind \
|
||||
--privileged \
|
||||
-e DOCKER_TLS_CERTDIR=/certs \
|
||||
-v docker-certs:/certs \
|
||||
docker:28.0.4-dind
|
||||
|
||||
# Run build container connected to DinD
|
||||
docker run --rm \
|
||||
-e DOCKER_HOST=tcp://dind:2376 \
|
||||
-e DOCKER_TLS_VERIFY=1 \
|
||||
-e DOCKER_CERT_PATH=/certs/client \
|
||||
-v docker-certs:/certs:ro \
|
||||
-v $(pwd):/workspace \
|
||||
-w /workspace \
|
||||
--link dind:dind \
|
||||
docker:28.0.4-cli \
|
||||
docker build -t myapp:latest .
|
||||
```
|
||||
|
||||
**Kubernetes DinD Sidecar (Forgejo Runner Pattern)**:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: forgejo-runner
|
||||
spec:
|
||||
containers:
|
||||
- name: runner
|
||||
image: code.forgejo.org/forgejo/runner:6.4.0
|
||||
env:
|
||||
- name: DOCKER_HOST
|
||||
value: tcp://localhost:2376
|
||||
- name: DOCKER_TLS_VERIFY
|
||||
value: "1"
|
||||
- name: DOCKER_CERT_PATH
|
||||
value: /certs/client
|
||||
volumeMounts:
|
||||
- name: docker-certs
|
||||
mountPath: /certs
|
||||
readOnly: true
|
||||
- name: runner-data
|
||||
mountPath: /data
|
||||
|
||||
- name: dind
|
||||
image: docker:28.0.4-dind
|
||||
securityContext:
|
||||
privileged: true
|
||||
env:
|
||||
- name: DOCKER_TLS_CERTDIR
|
||||
value: /certs
|
||||
volumeMounts:
|
||||
- name: docker-certs
|
||||
mountPath: /certs
|
||||
- name: docker-storage
|
||||
mountPath: /var/lib/docker
|
||||
|
||||
volumes:
|
||||
- name: docker-certs
|
||||
emptyDir: {}
|
||||
- name: runner-data
|
||||
emptyDir: {}
|
||||
- name: docker-storage
|
||||
emptyDir: {}
|
||||
```
|
||||
|
||||
This configuration runs a Forgejo Actions runner with a DinD sidecar, enabling containerized builds within Kubernetes pods.
|
||||
|
||||
### Local Development with Docker Compose
|
||||
|
||||
**Docker Compose Configuration**:
|
||||
|
||||
```yaml
|
||||
# docker-compose.yml
|
||||
version: '3.8'
|
||||
|
||||
services:
|
||||
app:
|
||||
build: .
|
||||
ports:
|
||||
- "8080:8080"
|
||||
environment:
|
||||
- DATABASE_URL=postgresql://user:pass@db:5432/appdb
|
||||
depends_on:
|
||||
- db
|
||||
- redis
|
||||
volumes:
|
||||
- ./src:/app/src
|
||||
|
||||
db:
|
||||
image: postgres:15
|
||||
environment:
|
||||
- POSTGRES_USER=user
|
||||
- POSTGRES_PASSWORD=pass
|
||||
- POSTGRES_DB=appdb
|
||||
volumes:
|
||||
- postgres-data:/var/lib/postgresql/data
|
||||
|
||||
redis:
|
||||
image: redis:7-alpine
|
||||
ports:
|
||||
- "6379:6379"
|
||||
|
||||
volumes:
|
||||
postgres-data:
|
||||
```
|
||||
|
||||
**Compose Commands**:
|
||||
|
||||
```bash
|
||||
# Start all services
|
||||
docker-compose up -d
|
||||
|
||||
# View logs
|
||||
docker-compose logs -f
|
||||
|
||||
# Stop services
|
||||
docker-compose down
|
||||
|
||||
# Rebuild and restart
|
||||
docker-compose up -d --build
|
||||
|
||||
# Run command in service
|
||||
docker-compose exec app /bin/bash
|
||||
|
||||
# Scale service
|
||||
docker-compose up -d --scale app=3
|
||||
```
|
||||
|
||||
### Image Management
|
||||
|
||||
**Image Operations**:
|
||||
|
||||
```bash
|
||||
# List images
|
||||
docker images
|
||||
|
||||
# Remove image
|
||||
docker rmi myapp:1.0
|
||||
|
||||
# Remove unused images
|
||||
docker image prune
|
||||
|
||||
# Remove all unused images
|
||||
docker image prune -a
|
||||
|
||||
# Inspect image layers
|
||||
docker history myapp:1.0
|
||||
```
|
||||
|
||||
**Registry Operations**:
|
||||
|
||||
```bash
|
||||
# Login to registry
|
||||
docker login registry.example.com
|
||||
|
||||
# Login with credentials
|
||||
echo $PASSWORD | docker login -u $USERNAME --password-stdin registry.example.com
|
||||
|
||||
# Push image
|
||||
docker push registry.example.com/myapp:1.0
|
||||
|
||||
# Pull image
|
||||
docker pull registry.example.com/myapp:1.0
|
||||
|
||||
# Search registry
|
||||
docker search nginx
|
||||
```
|
||||
|
||||
## Architecture
|
||||
|
||||
### Docker Architecture Overview
|
||||
|
||||
Docker follows a client-server architecture with several key components:
|
||||
|
||||
**Docker Client**: Command-line tool (docker CLI) that sends API requests to the Docker daemon. Developers interact with Docker through client commands like `docker run`, `docker build`, and `docker ps`.
|
||||
|
||||
**Docker Daemon (dockerd)**: Background service that manages containers, images, networks, and volumes. The daemon listens for Docker API requests and coordinates with lower-level runtime components.
|
||||
|
||||
**Containerd**: High-level container runtime that manages container lifecycle operations. Containerd handles image transfer and storage, container execution supervision, and low-level storage and network attachments.
|
||||
|
||||
**runc**: Low-level OCI (Open Container Initiative) runtime that creates and runs containers. Runc interfaces directly with Linux kernel features to spawn and manage container processes.
|
||||
|
||||
### Container Runtime Layers
|
||||
|
||||
Docker's layered architecture separates concerns across multiple components:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────┐
|
||||
│ Docker Client (CLI) │
|
||||
│ docker run, build, push │
|
||||
└────────────┬────────────────────┘
|
||||
│ Docker API
|
||||
┌────────────▼────────────────────┐
|
||||
│ Docker Daemon (dockerd) │
|
||||
│ API, Image management, Auth │
|
||||
└────────────┬────────────────────┘
|
||||
│ Container API
|
||||
┌────────────▼────────────────────┐
|
||||
│ Containerd │
|
||||
│ Lifecycle, Image pull/push │
|
||||
└────────────┬────────────────────┘
|
||||
│ OCI Runtime API
|
||||
┌────────────▼────────────────────┐
|
||||
│ runc │
|
||||
│ Namespace, cgroup creation │
|
||||
└────────────┬────────────────────┘
|
||||
│ System Calls
|
||||
┌────────────▼────────────────────┐
|
||||
│ Linux Kernel │
|
||||
│ namespaces, cgroups, seccomp │
|
||||
└─────────────────────────────────┘
|
||||
```
|
||||
|
||||
**Docker Daemon Layer**: Handles high-level operations like image building, authentication, and API endpoint management. The daemon translates user commands into lower-level runtime operations.
|
||||
|
||||
**Containerd Layer**: Manages container lifecycle independent of Docker-specific features. Containerd can be used directly by Kubernetes and other orchestrators, providing a standard container runtime interface.
|
||||
|
||||
**runc Layer**: Implements the OCI runtime specification, creating container processes with Linux kernel isolation features. Runc configures namespaces, cgroups, and security policies before executing container entrypoints.
|
||||
|
||||
### Linux Kernel Features
|
||||
|
||||
Docker leverages several Linux kernel capabilities for container isolation:
|
||||
|
||||
**Namespaces**: Provide process isolation by creating separate views of system resources:
|
||||
- **PID namespace**: Isolates process IDs so containers see only their own processes
|
||||
- **Network namespace**: Provides separate network stacks with unique IP addresses and routing tables
|
||||
- **Mount namespace**: Isolates filesystem mount points so containers have independent filesystem views
|
||||
- **UTS namespace**: Separates hostname and domain name
|
||||
- **IPC namespace**: Isolates inter-process communication resources like shared memory
|
||||
- **User namespace**: Maps container user IDs to different host user IDs for privilege separation
|
||||
|
||||
**Control Groups (cgroups)**: Limit and account for resource usage:
|
||||
- CPU allocation and throttling
|
||||
- Memory limits and swap control
|
||||
- Block I/O bandwidth limits
|
||||
- Network bandwidth control (via tc integration)
|
||||
|
||||
**Capabilities**: Fine-grained privilege control that breaks down root privileges into discrete capabilities. Containers run with reduced capability sets, dropping dangerous privileges like CAP_SYS_ADMIN.
|
||||
|
||||
**Seccomp**: Filters system calls that containerized processes can make, reducing the kernel attack surface. Docker applies a default seccomp profile blocking ~44 dangerous syscalls.
|
||||
|
||||
**AppArmor/SELinux**: Mandatory access control systems that enforce security policies on container processes, restricting file access and operations.
|
||||
|
||||
### Image Storage and OverlayFS
|
||||
|
||||
Docker uses storage drivers to manage image layers and container filesystems. The preferred storage driver is overlay2, which uses OverlayFS:
|
||||
|
||||
**Image Layers**: Docker images consist of read-only layers stacked on top of each other. Each Dockerfile instruction creates a new layer. Layers are shared between images, reducing storage requirements.
|
||||
|
||||
**Copy-on-Write (CoW)**: When a container modifies a file from an image layer, OverlayFS copies the file to the container's writable layer. The original image layer remains unchanged, enabling efficient image reuse.
|
||||
|
||||
**OverlayFS Structure**:
|
||||
```
|
||||
Container Writable Layer (upperdir)
|
||||
│
|
||||
├─ Modified files
|
||||
│
|
||||
Image Layers (lowerdir)
|
||||
│
|
||||
├─ Layer 3 (READ-ONLY)
|
||||
├─ Layer 2 (READ-ONLY)
|
||||
└─ Layer 1 (READ-ONLY)
|
||||
│
|
||||
Merged View (merged)
|
||||
│
|
||||
└─ Union of all layers
|
||||
```
|
||||
|
||||
**LowerDir**: Read-only image layers containing base filesystem and application files
|
||||
|
||||
**UpperDir**: Writable container layer where all changes are stored
|
||||
|
||||
**MergedDir**: Union mount that presents a unified view of all layers to the container
|
||||
|
||||
**WorkDir**: Internal working directory used by OverlayFS for atomic operations
|
||||
|
||||
When a container reads a file, OverlayFS serves it from the topmost layer where it exists. Writes always go to the upperdir, leaving image layers immutable.
|
||||
|
||||
### Networking Architecture
|
||||
|
||||
Docker provides several networking modes:
|
||||
|
||||
**Bridge Network**: Default network mode that creates a virtual bridge (docker0) on the host. Containers connect to the bridge and receive private IP addresses. Network Address Translation (NAT) enables outbound connectivity.
|
||||
|
||||
**Host Network**: Container shares the host's network namespace, using the host's IP address directly. Offers maximum network performance but reduces isolation.
|
||||
|
||||
**Overlay Network**: Multi-host networking for container communication across different Docker hosts. Used by Docker Swarm and can be integrated with Kubernetes.
|
||||
|
||||
**None**: Disables networking for maximum isolation.
|
||||
|
||||
### Docker-in-Docker (DinD) Architecture
|
||||
|
||||
Docker-in-Docker runs a nested Docker daemon inside a container. This is used in CI/CD runners to provide isolated build environments:
|
||||
|
||||
**Privileged Container**: DinD requires privileged mode to mount filesystems and create namespaces within the container. The `--privileged` flag grants extended capabilities.
|
||||
|
||||
**Separate Daemon**: A complete Docker daemon runs inside the container, managing its own containers, images, and networks independently of the host daemon.
|
||||
|
||||
**Certificate Management**: DinD uses mutual TLS authentication between the inner client and daemon. Certificates are shared through volumes mounted at `/certs`.
|
||||
|
||||
**Storage Driver**: The inner Docker daemon typically uses vfs or overlay2 storage driver. VFS provides maximum compatibility but larger storage overhead.
|
||||
|
||||
**Use in Forgejo Runners**:
|
||||
```yaml
|
||||
containers:
|
||||
- name: runner
|
||||
image: code.forgejo.org/forgejo/runner:6.4.0
|
||||
env:
|
||||
- name: DOCKER_HOST
|
||||
value: tcp://localhost:2376
|
||||
- name: DOCKER_TLS_VERIFY
|
||||
value: "1"
|
||||
|
||||
- name: dind
|
||||
image: docker:28.0.4-dind
|
||||
securityContext:
|
||||
privileged: true
|
||||
volumeMounts:
|
||||
- name: docker-certs
|
||||
mountPath: /certs
|
||||
```
|
||||
|
||||
The runner container connects to the DinD container via TCP, allowing workflow steps to execute docker commands for building and testing.
|
||||
|
||||
## Configuration
|
||||
|
||||
### Docker Daemon Configuration
|
||||
|
||||
The Docker daemon reads configuration from `/etc/docker/daemon.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"log-driver": "json-file",
|
||||
"log-opts": {
|
||||
"max-size": "10m",
|
||||
"max-file": "3"
|
||||
},
|
||||
"storage-driver": "overlay2",
|
||||
"storage-opts": [
|
||||
"overlay2.override_kernel_check=true"
|
||||
],
|
||||
"default-address-pools": [
|
||||
{
|
||||
"base": "172.17.0.0/16",
|
||||
"size": 24
|
||||
}
|
||||
],
|
||||
"dns": ["8.8.8.8", "8.8.4.4"],
|
||||
"insecure-registries": [],
|
||||
"registry-mirrors": [],
|
||||
"features": {
|
||||
"buildkit": true
|
||||
},
|
||||
"max-concurrent-downloads": 10,
|
||||
"max-concurrent-uploads": 5
|
||||
}
|
||||
```
|
||||
|
||||
**Key Configuration Options**:
|
||||
|
||||
* `log-driver`: Logging mechanism (json-file, syslog, journald, etc.)
|
||||
* `storage-driver`: Filesystem driver (overlay2, devicemapper, btrfs, zfs)
|
||||
* `insecure-registries`: Registries that don't require HTTPS
|
||||
* `registry-mirrors`: Mirror registries for faster pulls
|
||||
* `buildkit`: Enable BuildKit for improved build performance
|
||||
|
||||
**Apply Configuration Changes**:
|
||||
|
||||
```bash
|
||||
# Restart Docker daemon
|
||||
sudo systemctl restart docker
|
||||
|
||||
# Verify configuration
|
||||
docker info
|
||||
```
|
||||
|
||||
### Docker-in-Docker Configuration
|
||||
|
||||
**Environment Variables**:
|
||||
|
||||
* `DOCKER_TLS_CERTDIR`: Directory for TLS certificates (typically `/certs`)
|
||||
* `DOCKER_HOST`: Docker daemon address (e.g., `tcp://localhost:2376`)
|
||||
* `DOCKER_TLS_VERIFY`: Enable TLS verification (`1` or `0`)
|
||||
* `DOCKER_CERT_PATH`: Path to client certificates
|
||||
|
||||
**DinD Security Considerations**:
|
||||
|
||||
DinD requires privileged mode, which grants extended capabilities. Use DinD only in trusted environments:
|
||||
- CI/CD runners in isolated namespaces
|
||||
- Development environments
|
||||
- Build systems with network isolation
|
||||
|
||||
Avoid using DinD for untrusted workloads or multi-tenant environments.
|
||||
|
||||
## Integration Points
|
||||
|
||||
* **Kubernetes**: Can use Docker (via dockershim, deprecated) or containerd directly as container runtime
|
||||
* **Forgejo Actions**: Uses Docker-in-Docker for isolated build execution in CI/CD pipelines
|
||||
* **Container Registries**: Pushes and pulls images to/from OCI-compliant registries
|
||||
* **Development Environments**: Docker Desktop provides local container runtime for development
|
||||
* **Image Scanning Tools**: Integrates with security scanners like Trivy and Clair
|
||||
* **Monitoring Systems**: Exports metrics via Prometheus exporters and logging drivers
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Docker Daemon Won't Start
|
||||
|
||||
**Problem**: Docker daemon fails to start or crashes immediately
|
||||
|
||||
**Solution**:
|
||||
1. Check daemon logs:
|
||||
```bash
|
||||
sudo journalctl -u docker.service
|
||||
sudo cat /var/log/docker.log
|
||||
```
|
||||
|
||||
2. Verify kernel support:
|
||||
```bash
|
||||
docker info | grep -i kernel
|
||||
grep CONFIG_NAMESPACES /boot/config-$(uname -r)
|
||||
```
|
||||
|
||||
3. Test daemon in debug mode:
|
||||
```bash
|
||||
sudo dockerd --debug
|
||||
```
|
||||
|
||||
4. Check for port conflicts:
|
||||
```bash
|
||||
sudo netstat -tulpn | grep docker
|
||||
```
|
||||
|
||||
### Container Cannot Connect to Network
|
||||
|
||||
**Problem**: Container has no network connectivity or DNS resolution fails
|
||||
|
||||
**Solution**:
|
||||
1. Check container network mode:
|
||||
```bash
|
||||
docker inspect container-name | grep -i network
|
||||
```
|
||||
|
||||
2. Verify DNS configuration:
|
||||
```bash
|
||||
docker exec container-name cat /etc/resolv.conf
|
||||
docker exec container-name ping 8.8.8.8
|
||||
docker exec container-name ping google.com
|
||||
```
|
||||
|
||||
3. Check firewall rules:
|
||||
```bash
|
||||
sudo iptables -L -n | grep DOCKER
|
||||
```
|
||||
|
||||
4. Restart Docker network:
|
||||
```bash
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
|
||||
5. Recreate default bridge:
|
||||
```bash
|
||||
docker network rm bridge
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
|
||||
### Out of Disk Space
|
||||
|
||||
**Problem**: Docker runs out of disk space for images or containers
|
||||
|
||||
**Solution**:
|
||||
1. Check disk usage:
|
||||
```bash
|
||||
docker system df
|
||||
docker system df -v # Verbose output
|
||||
```
|
||||
|
||||
2. Remove unused containers:
|
||||
```bash
|
||||
docker container prune
|
||||
```
|
||||
|
||||
3. Remove unused images:
|
||||
```bash
|
||||
docker image prune -a
|
||||
```
|
||||
|
||||
4. Remove unused volumes:
|
||||
```bash
|
||||
docker volume prune
|
||||
```
|
||||
|
||||
5. Complete cleanup:
|
||||
```bash
|
||||
docker system prune -a --volumes
|
||||
```
|
||||
|
||||
6. Configure log rotation in `/etc/docker/daemon.json`:
|
||||
```json
|
||||
{
|
||||
"log-opts": {
|
||||
"max-size": "10m",
|
||||
"max-file": "3"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Docker Build Fails
|
||||
|
||||
**Problem**: Image build fails with errors or hangs
|
||||
|
||||
**Solution**:
|
||||
1. Build with verbose output:
|
||||
```bash
|
||||
docker build --progress=plain --no-cache -t myapp .
|
||||
```
|
||||
|
||||
2. Check Dockerfile syntax:
|
||||
```bash
|
||||
docker build --check -t myapp .
|
||||
```
|
||||
|
||||
3. Verify base image exists:
|
||||
```bash
|
||||
docker pull ubuntu:22.04
|
||||
```
|
||||
|
||||
4. Increase build memory (Docker Desktop):
|
||||
- Open Docker Desktop settings
|
||||
- Increase memory allocation to 4GB+
|
||||
|
||||
5. Check build context size:
|
||||
```bash
|
||||
docker build --progress=plain -t myapp . 2>&1 | grep "transferring context"
|
||||
```
|
||||
|
||||
6. Use `.dockerignore` to exclude large files:
|
||||
```
|
||||
# .dockerignore
|
||||
node_modules
|
||||
.git
|
||||
*.log
|
||||
```
|
||||
|
||||
### Docker-in-Docker Container Cannot Build Images
|
||||
|
||||
**Problem**: DinD container fails to build images or start daemon
|
||||
|
||||
**Solution**:
|
||||
1. Verify privileged mode:
|
||||
```bash
|
||||
docker inspect dind | grep -i privileged
|
||||
```
|
||||
|
||||
2. Check DinD daemon logs:
|
||||
```bash
|
||||
docker logs dind
|
||||
```
|
||||
|
||||
3. Verify certificate volumes:
|
||||
```bash
|
||||
docker exec dind ls -la /certs
|
||||
```
|
||||
|
||||
4. Test Docker client connection:
|
||||
```bash
|
||||
docker run --rm \
|
||||
-e DOCKER_HOST=tcp://dind:2376 \
|
||||
-e DOCKER_TLS_VERIFY=1 \
|
||||
-e DOCKER_CERT_PATH=/certs/client \
|
||||
-v docker-certs:/certs:ro \
|
||||
--link dind:dind \
|
||||
docker:28.0.4-cli \
|
||||
docker info
|
||||
```
|
||||
|
||||
5. Check storage driver:
|
||||
```bash
|
||||
docker exec dind docker info | grep "Storage Driver"
|
||||
```
|
||||
|
||||
### Permission Denied When Running Docker
|
||||
|
||||
**Problem**: User cannot run Docker commands without sudo
|
||||
|
||||
**Solution**:
|
||||
1. Add user to docker group:
|
||||
```bash
|
||||
sudo usermod -aG docker $USER
|
||||
```
|
||||
|
||||
2. Log out and back in to apply group changes
|
||||
|
||||
3. Verify group membership:
|
||||
```bash
|
||||
groups $USER
|
||||
```
|
||||
|
||||
4. Test Docker access:
|
||||
```bash
|
||||
docker ps
|
||||
```
|
||||
|
||||
5. If issue persists, check socket permissions:
|
||||
```bash
|
||||
sudo chmod 666 /var/run/docker.sock
|
||||
```
|
||||
|
||||
Note: Adding users to the docker group grants root-equivalent privileges. Only add trusted users.
|
||||
|
||||
## Additional Resources
|
||||
|
||||
* [Docker Documentation](https://docs.docker.com/)
|
||||
* [Docker Hub](https://hub.docker.com/)
|
||||
* [Dockerfile Best Practices](https://docs.docker.com/develop/dev-best-practices/)
|
||||
* [Containerd Documentation](https://containerd.io/)
|
||||
* [OCI Specifications](https://opencontainers.org/)
|
||||
* [Docker Security Best Practices](https://docs.docker.com/engine/security/)
|
||||
* [Kernel Namespace Documentation](https://man7.org/linux/man-pages/man7/namespaces.7.html)
|
||||
* [Control Groups (cgroups) Documentation](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html)
|
||||
|
|
@ -1,128 +0,0 @@
|
|||
---
|
||||
title: "Kubernetes"
|
||||
linkTitle: "Kubernetes"
|
||||
weight: 20
|
||||
description: >
|
||||
Container orchestration platform for managing containerized workloads
|
||||
---
|
||||
|
||||
{{% alert title="Draft" color="warning" %}}
|
||||
**Editorial Status**: This page is currently being developed.
|
||||
|
||||
* **Jira Ticket**: [TICKET-XXX](https://your-jira/browse/TICKET-XXX)
|
||||
* **Assignee**: [Name or Team]
|
||||
* **Status**: Draft
|
||||
* **Last Updated**: YYYY-MM-DD
|
||||
* **TODO**:
|
||||
* [ ] Add detailed component description
|
||||
* [ ] Include usage examples and code samples
|
||||
* [ ] Add architecture diagrams
|
||||
* [ ] Review and finalize content
|
||||
{{% /alert %}}
|
||||
|
||||
## Overview
|
||||
|
||||
[Detailed description of the component - what it is, what it does, and why it exists]
|
||||
|
||||
## Key Features
|
||||
|
||||
* [Feature 1]
|
||||
* [Feature 2]
|
||||
* [Feature 3]
|
||||
|
||||
## Purpose in EDP
|
||||
|
||||
[Explain the role this component plays in the Edge Developer Platform and how it contributes to the overall platform capabilities]
|
||||
|
||||
## Repository
|
||||
|
||||
**Code**: [Link to source code repository]
|
||||
|
||||
**Documentation**: [Link to component-specific documentation]
|
||||
|
||||
## Getting Started
|
||||
|
||||
### Prerequisites
|
||||
|
||||
* [Prerequisite 1]
|
||||
* [Prerequisite 2]
|
||||
|
||||
### Quick Start
|
||||
|
||||
[Step-by-step guide to get started with this component]
|
||||
|
||||
1. [Step 1]
|
||||
2. [Step 2]
|
||||
3. [Step 3]
|
||||
|
||||
### Verification
|
||||
|
||||
[How to verify the component is working correctly]
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### [Use Case 1]
|
||||
|
||||
[Example with code/commands showing common use case]
|
||||
|
||||
```bash
|
||||
# Example commands
|
||||
```
|
||||
|
||||
### [Use Case 2]
|
||||
|
||||
[Another common scenario]
|
||||
|
||||
## Integration Points
|
||||
|
||||
* **[Component A]**: [How it integrates]
|
||||
* **[Component B]**: [How it integrates]
|
||||
* **[Component C]**: [How it integrates]
|
||||
|
||||
## Architecture
|
||||
|
||||
[Optional: Add architectural diagrams and descriptions]
|
||||
|
||||
### Component Architecture (C4)
|
||||
|
||||
[Add C4 Container or Component diagrams showing the internal structure]
|
||||
|
||||
### Sequence Diagrams
|
||||
|
||||
[Add sequence diagrams showing key interaction flows with other components]
|
||||
|
||||
### Deployment Architecture
|
||||
|
||||
[Add infrastructure and deployment diagrams showing how the component is deployed]
|
||||
|
||||
## Configuration
|
||||
|
||||
[Key configuration options and how to set them]
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### [Common Issue 1]
|
||||
|
||||
**Problem**: [Description]
|
||||
|
||||
**Solution**: [How to fix]
|
||||
|
||||
### [Common Issue 2]
|
||||
|
||||
**Problem**: [Description]
|
||||
|
||||
**Solution**: [How to fix]
|
||||
|
||||
## Status
|
||||
|
||||
**Maturity**: [Production / Beta / Experimental]
|
||||
|
||||
## Additional Resources
|
||||
|
||||
* [Link to external documentation]
|
||||
* [Link to community resources]
|
||||
* [Link to related components]
|
||||
|
||||
## Documentation Notes
|
||||
|
||||
[Instructions for team members filling in this documentation - remove this section once complete]
|
||||
|
|
@ -1,128 +0,0 @@
|
|||
---
|
||||
title: "LXC"
|
||||
linkTitle: "LXC"
|
||||
weight: 30
|
||||
description: >
|
||||
Linux Containers for lightweight system-level virtualization
|
||||
---
|
||||
|
||||
{{% alert title="Draft" color="warning" %}}
|
||||
**Editorial Status**: This page is currently being developed.
|
||||
|
||||
* **Jira Ticket**: [TICKET-XXX](https://your-jira/browse/TICKET-XXX)
|
||||
* **Assignee**: [Name or Team]
|
||||
* **Status**: Draft
|
||||
* **Last Updated**: YYYY-MM-DD
|
||||
* **TODO**:
|
||||
* [ ] Add detailed component description
|
||||
* [ ] Include usage examples and code samples
|
||||
* [ ] Add architecture diagrams
|
||||
* [ ] Review and finalize content
|
||||
{{% /alert %}}
|
||||
|
||||
## Overview
|
||||
|
||||
[Detailed description of the component - what it is, what it does, and why it exists]
|
||||
|
||||
## Key Features
|
||||
|
||||
* [Feature 1]
|
||||
* [Feature 2]
|
||||
* [Feature 3]
|
||||
|
||||
## Purpose in EDP
|
||||
|
||||
[Explain the role this component plays in the Edge Developer Platform and how it contributes to the overall platform capabilities]
|
||||
|
||||
## Repository
|
||||
|
||||
**Code**: [Link to source code repository]
|
||||
|
||||
**Documentation**: [Link to component-specific documentation]
|
||||
|
||||
## Getting Started
|
||||
|
||||
### Prerequisites
|
||||
|
||||
* [Prerequisite 1]
|
||||
* [Prerequisite 2]
|
||||
|
||||
### Quick Start
|
||||
|
||||
[Step-by-step guide to get started with this component]
|
||||
|
||||
1. [Step 1]
|
||||
2. [Step 2]
|
||||
3. [Step 3]
|
||||
|
||||
### Verification
|
||||
|
||||
[How to verify the component is working correctly]
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### [Use Case 1]
|
||||
|
||||
[Example with code/commands showing common use case]
|
||||
|
||||
```bash
|
||||
# Example commands
|
||||
```
|
||||
|
||||
### [Use Case 2]
|
||||
|
||||
[Another common scenario]
|
||||
|
||||
## Integration Points
|
||||
|
||||
* **[Component A]**: [How it integrates]
|
||||
* **[Component B]**: [How it integrates]
|
||||
* **[Component C]**: [How it integrates]
|
||||
|
||||
## Architecture
|
||||
|
||||
[Optional: Add architectural diagrams and descriptions]
|
||||
|
||||
### Component Architecture (C4)
|
||||
|
||||
[Add C4 Container or Component diagrams showing the internal structure]
|
||||
|
||||
### Sequence Diagrams
|
||||
|
||||
[Add sequence diagrams showing key interaction flows with other components]
|
||||
|
||||
### Deployment Architecture
|
||||
|
||||
[Add infrastructure and deployment diagrams showing how the component is deployed]
|
||||
|
||||
## Configuration
|
||||
|
||||
[Key configuration options and how to set them]
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### [Common Issue 1]
|
||||
|
||||
**Problem**: [Description]
|
||||
|
||||
**Solution**: [How to fix]
|
||||
|
||||
### [Common Issue 2]
|
||||
|
||||
**Problem**: [Description]
|
||||
|
||||
**Solution**: [How to fix]
|
||||
|
||||
## Status
|
||||
|
||||
**Maturity**: [Production / Beta / Experimental]
|
||||
|
||||
## Additional Resources
|
||||
|
||||
* [Link to external documentation]
|
||||
* [Link to community resources]
|
||||
* [Link to related components]
|
||||
|
||||
## Documentation Notes
|
||||
|
||||
[Instructions for team members filling in this documentation - remove this section once complete]
|
||||
|
|
@ -1,128 +0,0 @@
|
|||
---
|
||||
title: "Infrastructure Provider"
|
||||
linkTitle: "Provider"
|
||||
weight: 40
|
||||
description: >
|
||||
Infrastructure provider abstraction for managing physical resources
|
||||
---
|
||||
|
||||
{{% alert title="Draft" color="warning" %}}
|
||||
**Editorial Status**: This page is currently being developed.
|
||||
|
||||
* **Jira Ticket**: [TICKET-XXX](https://your-jira/browse/TICKET-XXX)
|
||||
* **Assignee**: [Name or Team]
|
||||
* **Status**: Draft
|
||||
* **Last Updated**: YYYY-MM-DD
|
||||
* **TODO**:
|
||||
* [ ] Add detailed component description
|
||||
* [ ] Include usage examples and code samples
|
||||
* [ ] Add architecture diagrams
|
||||
* [ ] Review and finalize content
|
||||
{{% /alert %}}
|
||||
|
||||
## Overview
|
||||
|
||||
[Detailed description of the component - what it is, what it does, and why it exists]
|
||||
|
||||
## Key Features
|
||||
|
||||
* [Feature 1]
|
||||
* [Feature 2]
|
||||
* [Feature 3]
|
||||
|
||||
## Purpose in EDP
|
||||
|
||||
[Explain the role this component plays in the Edge Developer Platform and how it contributes to the overall platform capabilities]
|
||||
|
||||
## Repository
|
||||
|
||||
**Code**: [Link to source code repository]
|
||||
|
||||
**Documentation**: [Link to component-specific documentation]
|
||||
|
||||
## Getting Started
|
||||
|
||||
### Prerequisites
|
||||
|
||||
* [Prerequisite 1]
|
||||
* [Prerequisite 2]
|
||||
|
||||
### Quick Start
|
||||
|
||||
[Step-by-step guide to get started with this component]
|
||||
|
||||
1. [Step 1]
|
||||
2. [Step 2]
|
||||
3. [Step 3]
|
||||
|
||||
### Verification
|
||||
|
||||
[How to verify the component is working correctly]
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### [Use Case 1]
|
||||
|
||||
[Example with code/commands showing common use case]
|
||||
|
||||
```bash
|
||||
# Example commands
|
||||
```
|
||||
|
||||
### [Use Case 2]
|
||||
|
||||
[Another common scenario]
|
||||
|
||||
## Integration Points
|
||||
|
||||
* **[Component A]**: [How it integrates]
|
||||
* **[Component B]**: [How it integrates]
|
||||
* **[Component C]**: [How it integrates]
|
||||
|
||||
## Architecture
|
||||
|
||||
[Optional: Add architectural diagrams and descriptions]
|
||||
|
||||
### Component Architecture (C4)
|
||||
|
||||
[Add C4 Container or Component diagrams showing the internal structure]
|
||||
|
||||
### Sequence Diagrams
|
||||
|
||||
[Add sequence diagrams showing key interaction flows with other components]
|
||||
|
||||
### Deployment Architecture
|
||||
|
||||
[Add infrastructure and deployment diagrams showing how the component is deployed]
|
||||
|
||||
## Configuration
|
||||
|
||||
[Key configuration options and how to set them]
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### [Common Issue 1]
|
||||
|
||||
**Problem**: [Description]
|
||||
|
||||
**Solution**: [How to fix]
|
||||
|
||||
### [Common Issue 2]
|
||||
|
||||
**Problem**: [Description]
|
||||
|
||||
**Solution**: [How to fix]
|
||||
|
||||
## Status
|
||||
|
||||
**Maturity**: [Production / Beta / Experimental]
|
||||
|
||||
## Additional Resources
|
||||
|
||||
* [Link to external documentation]
|
||||
* [Link to community resources]
|
||||
* [Link to related components]
|
||||
|
||||
## Documentation Notes
|
||||
|
||||
[Instructions for team members filling in this documentation - remove this section once complete]
|
||||
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 92 KiB |
|
|
@ -31,10 +31,6 @@ While EdgeConnect is managed outwith our Edge Developer Platform, we have produc
|
|||
* EDP supplies tools such as [CLI](docs/components/deployments/edgeconnect/edgeconnect-client/) and [Terraform provider](/docs/components/orchestration/infrastructure/provider/)
|
||||
* Primary EDP products such as [Forgejo](/docs/components/forgejo/) are hosted on [OTC](/docs/components/deployments/otc/) rather than EdgeConnect
|
||||
|
||||
|
||||
SYSTEM IS NOT ACTUALLY DEPLOYED HERE
|
||||
JUST RUNNERS, CODER, individual components
|
||||
|
||||
## Purpose in EDP
|
||||
|
||||
Working with EdgeConnect allows us to ensure our work supports that of our colleagues, ultimately leading to a platform that is as broadly and deeply usable as possible. By working in a sovereign system we are encouraging European development, while sustainability features are offered by very few other clouds. It also gives us possibilities to work closely with other teams, ensuring both teams' work is better than would be possible otherwise.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "Development Environments"
|
||||
linkTitle: "DevEnvironments"
|
||||
title: Forgejo Actions
|
||||
linkTitle: Forgejo Actions
|
||||
weight: 30
|
||||
description: >
|
||||
Development environment provisioning and management
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Terraform provider for Edge cloud
|
||||
linkTitle: Edge provider
|
||||
linkTitle: Terraform provider
|
||||
weight: 20
|
||||
description: Custom Terraform provider for orchestrating Edge deployments
|
||||
---
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "Platform Overview"
|
||||
linkTitle: "Platform Overview"
|
||||
title: Edge Developer Platform
|
||||
linkTitle: Edge Developer Platform
|
||||
weight: 10
|
||||
description: >
|
||||
High-level overview of the Edge Developer Platform (EDP), its purpose, and product structure.
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Platform Orchestration"
|
||||
linkTitle: "Platform Orchestration"
|
||||
weight: 20
|
||||
title: Deployment
|
||||
linkTitle: Deployment
|
||||
weight: 10
|
||||
description: >
|
||||
Platform-level component provisioning via Stacks - Orchestrating the platform infrastructure itself
|
||||
---
|
||||
|
|
@ -351,13 +351,13 @@ Important ArgoCD configurations for platform orchestration:
|
|||
data:
|
||||
# Enable automatic sync
|
||||
application.instanceLabelKey: argocd.argoproj.io/instance
|
||||
|
||||
|
||||
# Repository credentials
|
||||
repositories: |
|
||||
- url: https://github.com/cnoe-io/stacks
|
||||
name: cnoe-stacks
|
||||
type: git
|
||||
|
||||
|
||||
# Resource exclusions
|
||||
resource.exclusions: |
|
||||
- apiGroups:
|
||||
509
content/en/docs/edp/deployment/basics/_index.md
Normal file
509
content/en/docs/edp/deployment/basics/_index.md
Normal file
|
|
@ -0,0 +1,509 @@
|
|||
---
|
||||
title: Basic Concepts
|
||||
linkTitle: Basic Concepts
|
||||
weight: 1
|
||||
description: >
|
||||
Platform-level component provisioning via Stacks - Orchestrating the platform infrastructure itself
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Platform Orchestration refers to the automation and management of the platform infrastructure itself. This includes the provisioning, configuration, and lifecycle management of all components that make up the Internal Developer Platform (IDP).
|
||||
|
||||
In the context of IPCEI-CIS, Platform Orchestration means:
|
||||
|
||||
- **Platform Bootstrap**: Initial setup of Kubernetes clusters and core services
|
||||
- **Platform Services Management**: Deployment and management of ArgoCD, Forgejo, Keycloak, etc.
|
||||
- **Infrastructure-as-Code**: Declarative management using Terraform and GitOps
|
||||
- **Multi-Cluster Orchestration**: Coordination across different Kubernetes clusters
|
||||
- **Platform Stacks**: Reusable bundles of platform components (CNOE concept)
|
||||
|
||||
### Target Audience
|
||||
|
||||
Platform Orchestration is primarily aimed at:
|
||||
|
||||
- **Platform Engineering Teams**: Teams that build and operate the IDP
|
||||
- **Infrastructure Architects**: Those responsible for the platform architecture
|
||||
- **SRE Teams**: Teams responsible for reliability and operations
|
||||
|
||||
## Key Features
|
||||
|
||||
### Declarative Platform Definition
|
||||
|
||||
The entire platform is defined declaratively as code:
|
||||
|
||||
- **GitOps-First**: Everything is versioned in Git and traceable
|
||||
- **Reproducibility**: The platform can be rebuilt at any time
|
||||
- **Environment Parity**: Consistency between Dev, Test, and Production
|
||||
- **Auditability**: Complete history of all changes
|
||||
|
||||
### Self-Bootstrapping
|
||||
|
||||
The platform can bootstrap itself:
|
||||
|
||||
1. **Initial Bootstrap**: Minimal tool (like `idpbuilder`) starts the platform
|
||||
2. **Self-Management**: After bootstrap, ArgoCD takes over management
|
||||
3. **Continuous Reconciliation**: Platform is continuously reconciled with Git state
|
||||
4. **Self-Healing**: Automatic recovery on deviations
|
||||
|
||||
### Stack-based Composition
|
||||
|
||||
Platform components are organized as reusable stacks (CNOE concept):
|
||||
|
||||
- **Modularity**: Components can be updated individually
|
||||
- **Reusability**: Stacks can be used across different environments
|
||||
- **Composability**: Compose complex platforms from simple building blocks
|
||||
- **Versioning**: Stacks can be versioned and tested
|
||||
|
||||
**In IPCEI-CIS**: The stacks concept from CNOE is the core organizational principle for platform components.
|
||||
|
||||
### Multi-Cluster Support
|
||||
|
||||
Platform Orchestration supports different cluster topologies:
|
||||
|
||||
- **Control Plane + Worker Clusters**: Centralized control, distributed workloads
|
||||
- **Hub-and-Spoke**: One management cluster manages multiple target clusters
|
||||
- **Federation**: Coordination across multiple independent clusters
|
||||
|
||||
## Purpose in EDP
|
||||
|
||||
Platform Orchestration is the foundation of the IPCEI-CIS Edge Developer Platform. It enables:
|
||||
|
||||
### Foundation for Developer Self-Service
|
||||
|
||||
Platform Orchestration ensures all services are available that developers need for self-service:
|
||||
|
||||
- **GitOps Engine** (ArgoCD) for continuous deployment
|
||||
- **Source Control** (Forgejo) for code and configuration management
|
||||
- **Identity Management** (Keycloak) for authentication and authorization
|
||||
- **Observability** (Grafana, Prometheus) for monitoring and logging
|
||||
- **CI/CD** (Forgejo Actions/Pipelines) for automated build and test
|
||||
|
||||
### Consistency Across Environments
|
||||
|
||||
Through declarative definition, consistency is guaranteed:
|
||||
|
||||
- Development, test, and production environments are identically configured
|
||||
- No "configuration drift" between environments
|
||||
- Predictable behavior across all stages
|
||||
|
||||
### Platform as Code
|
||||
|
||||
The platform itself is treated like software:
|
||||
|
||||
- **Version Control**: All changes are versioned in Git
|
||||
- **Code Review**: Platform changes go through review processes
|
||||
- **Testing**: Platform configurations can be tested
|
||||
- **Rollback**: Easy rollback on problems
|
||||
|
||||
### Reduced Operational Overhead
|
||||
|
||||
Automation reduces manual effort:
|
||||
|
||||
- No manual installation steps
|
||||
- Automatic updates and patching
|
||||
- Self-healing on failures
|
||||
- Standardized deployment processes
|
||||
|
||||
## Repository
|
||||
|
||||
**CNOE Reference Implementation**: [cnoe-io/stacks](https://github.com/cnoe-io/stacks)
|
||||
|
||||
**CNOE idpbuilder**: [cnoe-io/idpbuilder](https://github.com/cnoe-io/idpbuilder)
|
||||
|
||||
**Documentation**: [CNOE.io Documentation](https://cnoe.io/docs/)
|
||||
|
||||
## Getting Started
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- **Docker**: For local Kubernetes clusters (Kind)
|
||||
- **kubectl**: Kubernetes CLI tool
|
||||
- **Git**: For repository management
|
||||
- **idpbuilder**: CNOE bootstrap tool
|
||||
|
||||
### Quick Start
|
||||
|
||||
Platform Orchestration with CNOE Reference Implementation:
|
||||
|
||||
```bash
|
||||
# 1. Install idpbuilder
|
||||
curl -fsSL https://cnoe.io/install.sh | bash
|
||||
|
||||
# 2. Bootstrap platform
|
||||
idpbuilder create \
|
||||
--use-path-routing \
|
||||
--package-dir https://github.com/cnoe-io/stacks//ref-implementation
|
||||
|
||||
# 3. Wait for platform ready (ca. 10 minutes)
|
||||
kubectl get applications -A
|
||||
```
|
||||
|
||||
### Verification
|
||||
|
||||
Verify the platform is running correctly:
|
||||
|
||||
```bash
|
||||
# Get platform secrets (credentials)
|
||||
idpbuilder get secrets
|
||||
|
||||
# Check all ArgoCD applications
|
||||
kubectl get applications -n argocd
|
||||
|
||||
# Expected: All applications "Synced" and "Healthy"
|
||||
```
|
||||
|
||||
Access URLs (with path-routing):
|
||||
|
||||
- **ArgoCD**: `https://cnoe.localtest.me:8443/argocd`
|
||||
- **Forgejo**: `https://cnoe.localtest.me:8443/gitea`
|
||||
- **Keycloak**: `https://cnoe.localtest.me:8443/keycloak`
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### Use Case 1: Platform Bootstrap
|
||||
|
||||
Initial bootstrapping of a new platform instance:
|
||||
|
||||
```bash
|
||||
idpbuilder create \
|
||||
--use-path-routing \
|
||||
--package-dir https://github.com/cnoe-io/stacks//ref-implementation \
|
||||
--log-level debug
|
||||
|
||||
# Workflow:
|
||||
# 1. Creates Kind cluster
|
||||
# 2. Installs ingress-nginx
|
||||
# 3. Clones and installs ArgoCD
|
||||
# 4. Installs Forgejo
|
||||
# 5. Waits for core services
|
||||
# 6. Creates technical users
|
||||
# 7. Configures Git repositories
|
||||
# 8. Installs remaining stacks via ArgoCD
|
||||
```
|
||||
|
||||
After approximately 10 minutes, the platform is fully deployed.
|
||||
|
||||
### Use Case 2: Adding New Platform Components
|
||||
|
||||
Add new platform components via ArgoCD:
|
||||
|
||||
```bash
|
||||
# Create ArgoCD Application for new component
|
||||
cat <<EOF | kubectl apply -f -
|
||||
apiVersion: argoproj.io/v1alpha1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: external-secrets
|
||||
namespace: argocd
|
||||
spec:
|
||||
project: default
|
||||
source:
|
||||
repoURL: https://charts.external-secrets.io
|
||||
targetRevision: 0.9.9
|
||||
chart: external-secrets
|
||||
destination:
|
||||
server: https://kubernetes.default.svc
|
||||
namespace: external-secrets-system
|
||||
syncPolicy:
|
||||
automated:
|
||||
prune: true
|
||||
selfHeal: true
|
||||
syncOptions:
|
||||
- CreateNamespace=true
|
||||
EOF
|
||||
```
|
||||
|
||||
### Use Case 3: Platform Updates
|
||||
|
||||
Update platform components:
|
||||
|
||||
```bash
|
||||
# 1. Update via Git (GitOps)
|
||||
cd your-platform-config-repo
|
||||
git pull
|
||||
|
||||
# 2. Update stack version
|
||||
vim argocd/applications/component.yaml
|
||||
# Change targetRevision to new version
|
||||
|
||||
# 3. Commit and push
|
||||
git add .
|
||||
git commit -m "Update component to v1.2.3"
|
||||
git push
|
||||
|
||||
# 4. ArgoCD will automatically sync
|
||||
# 5. Monitor the update
|
||||
argocd app sync component --watch
|
||||
```
|
||||
|
||||
## Integration Points
|
||||
|
||||
### ArgoCD Integration
|
||||
|
||||
- **Bootstrap**: ArgoCD is initially installed via idpbuilder
|
||||
- **Self-Management**: After bootstrap, ArgoCD manages itself via Application CRD
|
||||
- **Platform Coordination**: ArgoCD orchestrates all other platform components
|
||||
- **Health Monitoring**: ArgoCD monitors health status of all platform services
|
||||
|
||||
### Forgejo Integration
|
||||
|
||||
- **Source of Truth**: Git repositories contain all platform definitions
|
||||
- **GitOps Workflow**: Changes in Git trigger platform updates
|
||||
- **Backup**: Git serves as backup of platform configuration
|
||||
- **Audit Trail**: Git history documents all platform changes
|
||||
- **CI/CD**: Forgejo Actions can automate platform operations
|
||||
|
||||
### Terraform Integration
|
||||
|
||||
- **Infrastructure Provisioning**: Terraform provisions cloud resources for platform
|
||||
- **State Management**: Terraform state tracks infrastructure
|
||||
- **Integration**: Terraform can be triggered via Forgejo pipelines
|
||||
- **Multi-Cloud**: Support for multiple cloud providers
|
||||
|
||||
## Architecture
|
||||
|
||||
### Platform Orchestration Flow
|
||||
|
||||
```text
|
||||
┌─────────────────┐
|
||||
│ idpbuilder │ Bootstrap Tool
|
||||
│ (Initial Run) │
|
||||
└────────┬────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ Kubernetes Cluster │
|
||||
│ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ ArgoCD │────────▶│ Forgejo │ │
|
||||
│ │ (GitOps) │ │ (Git Repo) │ │
|
||||
│ └──────┬───────┘ └──────────────┘ │
|
||||
│ │ │
|
||||
│ │ Monitors & Syncs │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ ┌──────────────────────────────────────┐ │
|
||||
│ │ Platform Stacks │ │
|
||||
│ │ │ │
|
||||
│ │ ┌──────────┐ ┌──────────┐ │ │
|
||||
│ │ │Forgejo │ │Keycloak │ │ │
|
||||
│ │ └──────────┘ └──────────┘ │ │
|
||||
│ │ ┌──────────┐ ┌──────────┐ │ │
|
||||
│ │ │Observ- │ │Ingress │ │ │
|
||||
│ │ │ability │ │ │ │ │
|
||||
│ │ └──────────┘ └──────────┘ │ │
|
||||
│ └──────────────────────────────────────┘ │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Platform Bootstrap Sequence
|
||||
|
||||
The idpbuilder executes the following workflow:
|
||||
|
||||
1. Create Kind Kubernetes cluster
|
||||
2. Install ingress-nginx controller
|
||||
3. Install ArgoCD
|
||||
4. Install Forgejo Git server
|
||||
5. Wait for services to be ready
|
||||
6. Create technical users in Forgejo
|
||||
7. Create repository for platform state in Forgejo
|
||||
8. Push platform stacks to Forgejo
|
||||
9. Create ArgoCD Applications for all stacks
|
||||
10. ArgoCD takes over continuous synchronization
|
||||
|
||||
### Deployment Architecture
|
||||
|
||||
The platform is deployed in different namespaces:
|
||||
|
||||
- `argocd`: ArgoCD and its components
|
||||
- `gitea`: Forgejo Git server
|
||||
- `keycloak`: Identity and access management
|
||||
- `observability`: Prometheus, Grafana, etc.
|
||||
- `ingress-nginx`: Ingress controller
|
||||
|
||||
## Configuration
|
||||
|
||||
### idpbuilder Configuration
|
||||
|
||||
Key configuration options for idpbuilder:
|
||||
|
||||
```bash
|
||||
# Path-based routing (recommended for local development)
|
||||
idpbuilder create --use-path-routing
|
||||
|
||||
# Custom package directory
|
||||
idpbuilder create --package-dir /path/to/custom/packages
|
||||
|
||||
# Custom Kind cluster config
|
||||
idpbuilder create --kind-config custom-kind.yaml
|
||||
|
||||
# Enable debug logging
|
||||
idpbuilder create --log-level debug
|
||||
```
|
||||
|
||||
### ArgoCD Configuration
|
||||
|
||||
Important ArgoCD configurations for platform orchestration:
|
||||
|
||||
```yaml
|
||||
# argocd-cm ConfigMap
|
||||
data:
|
||||
# Enable automatic sync
|
||||
application.instanceLabelKey: argocd.argoproj.io/instance
|
||||
|
||||
# Repository credentials
|
||||
repositories: |
|
||||
- url: https://github.com/cnoe-io/stacks
|
||||
name: cnoe-stacks
|
||||
type: git
|
||||
|
||||
# Resource exclusions
|
||||
resource.exclusions: |
|
||||
- apiGroups:
|
||||
- cilium.io
|
||||
kinds:
|
||||
- CiliumIdentity
|
||||
```
|
||||
|
||||
### Platform Stack Configuration
|
||||
|
||||
Configuration of platform stacks via Kustomize:
|
||||
|
||||
```yaml
|
||||
# kustomization.yaml
|
||||
apiVersion: kustomize.config.k8s.io/v1beta1
|
||||
kind: Kustomization
|
||||
|
||||
namespace: platform-system
|
||||
|
||||
resources:
|
||||
- argocd-app.yaml
|
||||
- forgejo-app.yaml
|
||||
- keycloak-app.yaml
|
||||
|
||||
patches:
|
||||
- target:
|
||||
kind: Application
|
||||
patch: |-
|
||||
- op: add
|
||||
path: /spec/syncPolicy
|
||||
value:
|
||||
automated:
|
||||
prune: true
|
||||
selfHeal: true
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Platform not reachable
|
||||
|
||||
**Problem**: After `idpbuilder create`, platform services are not reachable
|
||||
|
||||
**Solution**:
|
||||
|
||||
```bash
|
||||
# 1. Check if all pods are running
|
||||
kubectl get pods -A
|
||||
|
||||
# 2. Check ArgoCD application status
|
||||
kubectl get applications -n argocd
|
||||
|
||||
# 3. Check ingress
|
||||
kubectl get ingress -A
|
||||
|
||||
# 4. Verify DNS resolution
|
||||
nslookup cnoe.localtest.me
|
||||
|
||||
# 5. Check idpbuilder logs
|
||||
idpbuilder get logs
|
||||
```
|
||||
|
||||
### ArgoCD Applications not synchronized
|
||||
|
||||
**Problem**: ArgoCD Applications show status "OutOfSync"
|
||||
|
||||
**Solution**:
|
||||
|
||||
```bash
|
||||
# 1. Check application details
|
||||
argocd app get <app-name>
|
||||
|
||||
# 2. View sync status
|
||||
argocd app sync <app-name> --dry-run
|
||||
|
||||
# 3. Force sync
|
||||
argocd app sync <app-name> --force
|
||||
|
||||
# 4. Check for errors in ArgoCD logs
|
||||
kubectl logs -n argocd deployment/argocd-application-controller
|
||||
```
|
||||
|
||||
### Git Repository Connection Issues
|
||||
|
||||
**Problem**: ArgoCD cannot access Git repository
|
||||
|
||||
**Solution**:
|
||||
|
||||
```bash
|
||||
# 1. Verify repository configuration
|
||||
argocd repo list
|
||||
|
||||
# 2. Test connection
|
||||
argocd repo get https://your-git-repo
|
||||
|
||||
# 3. Check credentials
|
||||
kubectl get secret -n argocd
|
||||
|
||||
# 4. Re-add repository with correct credentials
|
||||
argocd repo add https://your-git-repo \
|
||||
--username <user> \
|
||||
--password <token>
|
||||
```
|
||||
|
||||
## Platform Orchestration Best Practices
|
||||
|
||||
Based on experience and [CNCF Guidelines](https://tag-app-delivery.cncf.io/whitepapers/platforms/):
|
||||
|
||||
1. **Start Simple**: Begin with the CNOE reference stack, extend gradually
|
||||
2. **Automate Everything**: Manual platform changes are anti-pattern
|
||||
3. **Monitor Continuously**: Use observability tools for platform health
|
||||
4. **Document Well**: Platform documentation is essential for adoption
|
||||
5. **Version Everything**: All platform components should be versioned
|
||||
6. **Test Changes**: Platform updates should be tested in non-prod
|
||||
7. **Plan for Disaster**: Backup and disaster recovery strategies are important
|
||||
8. **Use Stacks**: Organize platform components as reusable stacks
|
||||
|
||||
## Status
|
||||
|
||||
**Maturity**: Production (for CNOE Reference Implementation)
|
||||
|
||||
**Stability**: Stable
|
||||
|
||||
**Support**: Community Support via CNOE Community
|
||||
|
||||
## Additional Resources
|
||||
|
||||
### CNOE Resources
|
||||
|
||||
- [CNOE Official Website](https://cnoe.io/)
|
||||
- [CNOE GitHub Organization](https://github.com/cnoe-io)
|
||||
- [CNOE Reference Implementation](https://github.com/cnoe-io/stacks)
|
||||
- [CNOE Community Slack](https://cloud-native.slack.com/archives/C05TN9WFN5S)
|
||||
|
||||
### Platform Engineering
|
||||
|
||||
- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)
|
||||
- [Platform Engineering Maturity Model](https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/)
|
||||
- [Team Topologies](https://teamtopologies.com/) - Organizational patterns
|
||||
|
||||
### GitOps
|
||||
|
||||
- [GitOps Working Group](https://opengitops.dev/)
|
||||
- [ArgoCD Best Practices](https://argo-cd.readthedocs.io/en/stable/user-guide/best_practices/)
|
||||
- [GitOps Principles](https://opengitops.dev/)
|
||||
|
||||
### CNOE Stacks
|
||||
|
||||
- [Understanding CNOE Stacks](https://cnoe.io/docs/reference-implementation/stacks/)
|
||||
- [Creating Custom Stacks](https://cnoe.io/docs/reference-implementation/customization/)
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Orchestration"
|
||||
linkTitle: "Orchestration"
|
||||
weight: 10
|
||||
title: Platform Orchestration
|
||||
linkTitle: Platform Orchestration
|
||||
weight: 1
|
||||
description: >
|
||||
Orchestration in the context of Platform Engineering - coordinating infrastructure, platform, and application delivery.
|
||||
---
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Orchestration tools
|
||||
linkTitle: Orchestration tools
|
||||
title: Infrastructure as Code
|
||||
linkTitle: Infrastructure as Code
|
||||
weight: 10
|
||||
description: >
|
||||
Infrastructure deployment and catalog management (infra-deploy, infra-catalogue)
|
||||
|
Before Width: | Height: | Size: 333 KiB After Width: | Height: | Size: 333 KiB |
|
Before Width: | Height: | Size: 188 KiB After Width: | Height: | Size: 188 KiB |
|
Before Width: | Height: | Size: 146 KiB After Width: | Height: | Size: 146 KiB |
|
Before Width: | Height: | Size: 82 KiB After Width: | Height: | Size: 82 KiB |
8
content/en/docs/edp/deployment/otc.md
Normal file
8
content/en/docs/edp/deployment/otc.md
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
title: Deploying to OTC
|
||||
linkTitle: Deploying to OTC
|
||||
weight: 100
|
||||
description: TODO
|
||||
---
|
||||
|
||||
Patrick's page
|
||||
10
content/en/docs/edp/documentationsystem.md
Normal file
10
content/en/docs/edp/documentationsystem.md
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
title: "Documentation System"
|
||||
linkTitle: "Documentation System"
|
||||
weight: 100
|
||||
description: The developer 'documentation as code' documentation System we use ourselfes and over to use for each development team.
|
||||
---
|
||||
|
||||
We have a documentation system.
|
||||
|
||||
It is in this repo: ...
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Forgejo"
|
||||
linkTitle: "Forgejo"
|
||||
weight: 20
|
||||
title: Forgejo
|
||||
linkTitle: Forgejo
|
||||
weight: 5
|
||||
description: Forgejo provides source code management, project management, and CI/CD automation for the EDP.
|
||||
---
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ graph TD
|
|||
Dev[DevOps Engineer] -->|Triggers| Pipeline[Deployment Pipeline]
|
||||
Pipeline -->|Executes| TF[Terraform]
|
||||
end
|
||||
|
||||
|
||||
subgraph "Provisioned Infrastructure"
|
||||
TF -->|Provisions| CCE[(CCE K8s Cluster)]
|
||||
TF -->|Provisions| RDS[(RDS PostgreSQL)]
|
||||
|
|
@ -44,12 +44,12 @@ graph TD
|
|||
TF -->|Provisions| S3[(OBS S3 Bucket)]
|
||||
TF -->|Provisions| CSS[(CSS Elasticsearch)]
|
||||
end
|
||||
|
||||
|
||||
subgraph "Application Layer (on CCE K8s)"
|
||||
Pipeline -->|Helm Chart| Argo[ArgoCD]
|
||||
Argo -->|Deploys| ForgejoApp[Forgejo]
|
||||
end
|
||||
|
||||
|
||||
CCE -- Runs --> Argo
|
||||
CCE -- Runs --> ForgejoApp
|
||||
ForgejoApp -->|Connects| RDS
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "Forgejo Actions"
|
||||
linkTitle: "Actions"
|
||||
title: Forgejo Actions
|
||||
linkTitle: Forgejo Actions
|
||||
weight: 10
|
||||
description: GitHub Actions-compatible CI/CD automation
|
||||
---
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: "Action Runner"
|
||||
linkTitle: "Runner"
|
||||
title: Runners
|
||||
linkTitle: Runners
|
||||
weight: 20
|
||||
description: >
|
||||
Self-hosted runner infrastructure with orchestration capabilities
|
||||
|
|
@ -42,7 +42,7 @@ A actions runner are executing Forgejo actions, which can be used to build, test
|
|||
|
||||
## Repository
|
||||
|
||||
**Code**:
|
||||
**Code**:
|
||||
- [Runner on edge connect using GARM](https://edp.buildth.ing/DevFW-CICD/garm-provider-edge-connect/src/branch/main/runner)
|
||||
- [Static runner](https://edp.buildth.ing/DevFW-CICD/stacks/src/branch/main/template/stacks/forgejo/forgejo-runner/dind-docker.yaml)
|
||||
|
||||
|
|
@ -113,7 +113,7 @@ Container-based runners execute within isolated containers using OCI-compliant r
|
|||
### Prerequisites
|
||||
|
||||
* Forgejo instance
|
||||
* Runner registration token has been generated for a given scope
|
||||
* Runner registration token has been generated for a given scope
|
||||
* Global runners in `admin settings > actions > runner > Create new runner`
|
||||
* Organization runners in `organization settings > actions > runner > Create new runner`
|
||||
* Repository runners in `repository settings > actions > runner > Create new runner`
|
||||
|
|
@ -153,8 +153,8 @@ sequenceDiagram
|
|||
|
||||
## Configuration
|
||||
|
||||
There is a sophisticated [configuration file](https://forgejo.org/docs/latest/admin/actions/runner-installation/#configuration), where finetuning can be done.
|
||||
The most important thing is done by using labels to define the execution environment.
|
||||
There is a sophisticated [configuration file](https://forgejo.org/docs/latest/admin/actions/runner-installation/#configuration), where finetuning can be done.
|
||||
The most important thing is done by using labels to define the execution environment.
|
||||
|
||||
The label `ubuntu-latest:docker://ghcr.io/catthehacker/ubuntu:act-22.04` (as used in [example runner](https://edp.buildth.ing/DevFW-CICD/stacks/src/branch/main/template/stacks/forgejo/forgejo-runner/dind-docker.yaml)). That a job that uses `ubuntu-latest` label will be executed as docker container inside the `ghcr.io/catthehacker/ubuntu:act-22.04` image.
|
||||
|
||||
|
|
@ -164,7 +164,7 @@ Alternatives to `docker` are [`lxc`](https://forgejo.org/docs/latest/admin/actio
|
|||
|
||||
### In containerized environments, i want to build container images
|
||||
|
||||
**Problem**: In containerized environment, containers usually do not have many privileges. To start or build containers additional privleges, usually root is required inside of the kernel, the container runtime needs to manage linux namespaces and cgroups.
|
||||
**Problem**: In containerized environment, containers usually do not have many privileges. To start or build containers additional privleges, usually root is required inside of the kernel, the container runtime needs to manage linux namespaces and cgroups.
|
||||
|
||||
**Solution**: A partial solution for this is `buildkitd` utilizing `rootlesskit`. This allows containers to be **built** in a non root environment. You can find examples here: [Examples](https://github.com/moby/buildkit/tree/master/examples/kubernetes).
|
||||
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Runner Orchestration
|
||||
linkTitle: Runner Orchestration
|
||||
title: Orchestration with GARM
|
||||
linkTitle: Orchestration with GARM
|
||||
weight: 30
|
||||
description: Using GARM to manage short-lived Forgejo runners
|
||||
---
|
||||
|
Before Width: | Height: | Size: 218 KiB After Width: | Height: | Size: 218 KiB |
|
Before Width: | Height: | Size: 122 KiB After Width: | Height: | Size: 122 KiB |
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Getting Started"
|
||||
linkTitle: "Getting Started"
|
||||
weight: 20
|
||||
weight: 1
|
||||
description: >
|
||||
Quick start guides and onboarding information for the Edge Developer Platform.
|
||||
---
|
||||
|
Before Width: | Height: | Size: 50 KiB After Width: | Height: | Size: 50 KiB |
|
Before Width: | Height: | Size: 177 KiB After Width: | Height: | Size: 177 KiB |
|
Before Width: | Height: | Size: 68 KiB After Width: | Height: | Size: 68 KiB |
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
Loading…
Add table
Add a link
Reference in a new issue