Initial commit

.github/workflows/build-and-deploy.yml

@@ -0,0 +1,40 @@
+name: Build and Deploy
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  build-and-deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v3
+
+      - name: Set up Python
+        uses: actions/setup-python@v4
+        with:
+          python-version: '3.x'
+
+      - name: Install dependencies
+        run: |
+          pip install -r requirements.txt
+
+      - name: Build MkDocs site and PDF
+        run: make build
+
+      - name: Deploy to GitHub Pages
+        uses: peaceiris/actions-gh-pages@v3
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          publish_dir: ./site
+
+      - name: Create Release and Upload PDF
+        uses: softprops/action-gh-release@v1
+        with:
+          files: ./site/acp_terraform_guide.pdf
+          name: Release ${{ github.sha }}
+          tag_name: release-${{ github.sha }}
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.gitignore

@@ -0,0 +1,165 @@
+site/*
+.DS_Store
+
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#pdm.lock
+#   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
+#   in version control.
+#   https://pdm.fming.dev/latest/usage/project/#working-with-version-control
+.pdm.toml
+.pdm-python
+.pdm-build/
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+#.idea/

.vscode/settings.json

@@ -0,0 +1,3 @@
+{
+    "makefile.configureOnOpen": false
+}

Makefile

@@ -0,0 +1,11 @@
+.PHONY: serve build pdf clean
+
+serve:
+	mkdocs serve
+
+build:
+	mkdocs build
+
+clean:
+	rm -rf site
+	rm -f acp_terraform_guide.pdf

README.md

@@ -0,0 +1,41 @@
+# IaC Guidebook For ACP - Terraform Edition
+
+This little guide provides detailed instructions on implementing Infrastructure as Code (IaC) practices using Terraform within the Alauda Container Platform (ACP) environment.
+
+## Local Development
+
+### Environment Setup
+
+1. Ensure you have Python 3.x installed
+2. Install dependencies:
+   ```
+   pip install -r requirements.txt
+   ```
+
+### Local Preview
+
+Use the following command to preview the website locally:
+```
+make serve
+```
+Then in your browser, open http://localhost:8000 to view the website.
+
+### Build Static Website
+
+Use the following command to build the static website:
+```
+make build
+```
+The built files will be located in the `site/` directory.
+
+## Automated Deployment
+
+This project uses GitHub Actions for automated deployment. Every time you push to the `main` branch, the following actions will be triggered:
+
+1. Build the MkDocs static website
+2. Deploy the static website to GitHub Pages
+3. Generate the PDF file
+4. Create a new Release
+5. Upload the PDF file to the Release
+
+You can view the detailed workflow configuration in the `.github/workflows/build-and-deploy.yml` file.

guide/FQA.md

@@ -0,0 +1,11 @@
+## Why choose alekc/kubectl as the Provider?
+
+We recommend using the [alekc/kubectl provider](https://registry.terraform.io/providers/alekc/kubectl/latest) instead of the [hashicorp/kubernetes provider](https://registry.terraform.io/providers/hashicorp/kubernetes/latest). This recommendation is based on the following considerations:
+
+- **Broader Compatibility**: The alekc/kubectl Provider manages resources by directly executing kubectl commands. This approach supports all types of Kubernetes resources, including those provided through aggregated API servers. In contrast, the official Kubernetes Provider relies on server-side apply capabilities, which may be limited in certain situations.
+
+- **More Flexible Deployment Process**: During the `terraform plan` phase, the official Kubernetes provider requires that the CRDs (Custom Resource Definitions) for all resources being used already exist in the target cluster. This means users cannot deploy resource CRDs and resource instances simultaneously within the same Terraform repository. The alekc/kubectl provider, however, does not need to verify the existence of CRDs during the plan phase, offering greater flexibility.
+
+- **Simplified Resource Management**: The alekc/kubectl provider allows direct use of native Kubernetes YAML definitions to manage resources. For users familiar with Kubernetes, this can significantly reduce the learning curve and simplify the resource management process.
+
+- **Better Version Compatibility**: Since the alekc/kubectl provider relies on the kubectl command-line tool, it typically adapts better to different versions of Kubernetes clusters, reducing the occurrence of version compatibility issues.