早前,GitHub 发布 GitHub Actions 项目,开发者可通过 GitHub Actions 存储和搜索代码,部分代码可直接运行。本文尝试使用 AWS Lambda 和 API Gateway 作为基本 API,编写应用程序原型并用名为 gourmet 的容器运行函数,虽然这可能不会让代码易于管理,但至少不需要写 API 或者 Web 应用程序。
正如 Lambda 函数在 AWS 中运行一样,Github Actions 是一种强大的管理方式,可直接扩展应用。使用 AWS Lambda,可将代码挂接到几乎任何事件上,比如 EC2 创建、终止、DNS 记录更改等,不需要运行服务器,只需加载代码就能正常工作。
本文作者针对此做了一些尝试,但需要 CI 服务器。为了拥有可测试的 kubernetes 集群,作者自建私有存储库,目前因内部有些混乱暂不准备开源。
无论如何,以下是项目文件夹:
├── .github
│ ├── actions
│ │ ├── deploy
│ │ │ ├── deploy
│ │ │ └── Dockerfile
│ │ └── dryrun
│ │ ├── Dockerfile
│ │ └── dryrun
│ └── main.workflow
└── kubernetes
├── digitalocean.yaml
├── external-dns.yaml
├── micro.yaml
├── namespaces.yaml
├── nginx.yaml
└── openvpn.yaml
kubernetes 目录包含集群安装的所有东西。对于此存储库的每次新推送,需要检查是否可用命令 kubectl apply -f./kubernetes --dryrun 将其应用于 kubernetes 集群,并且当合并 PR 时,应用更改。
因此,作者在.github/main.workflow 中创办了工作流:
## Workflow defines what we want to call a set of actions.
## For every new push check if the changes can be applied to kubernetes ## using the action called: kubectl dryrun
workflow "after a push check if they apply to kubernetes" {
on = "push"
resolves = ["kubectl dryrun"]
}
## When a PR is merged trigger the action: kubectl deploy. To apply the new code to master.
workflow "on merge to master deploy on kubernetes" {
on = "pull_request"
resolves = ["kubectl deploy"]
}
## This is the action that checks if the push can be applied to kubernetes
action "kubectl dryrun" {
uses = "./.github/actions/dryrun"
secrets = ["KUBECONFIG"]
}
## This is the action that applies the change to kubernetes
action "kubectl deploy" {
uses = "./.github/actions/deploy"
secrets = ["KUBECONFIG"]
}
secrets 是一组环境变量,可从外部设置值。如果帐户启用 GitHub Action,则每个存储库的 Setting 都会有一个名为 secrets 的新标签。
本例,作者将 KUBECONFIG 设置为 kubeconfig 文件的 base64,允许 GitHub Action 授权给 Kubernetes 集群。
两个操作类似,第一个操作位于 .github/actions/dryrun 目录:
├── .github
├── actions
└── dryrun
├── Dockerfile
└── dryrun
包含一个 Dockerfile
FROM alpine:latest
## The action name displayed by GitHub
LABEL "com.github.actions.name"="kubectl dryrun"
## The description for the action
LABEL "com.github.actions.description"="Check the kubernetes change to apply."
## https://developer.github.com/actions/creating-github-actions/creating-a-docker-container/#supported-feather-icons
LABEL "com.github.actions.icon"="check"
## The color of the action icon
LABEL "com.github.actions.color"="blue"
RUN apk add --no-cache \
bash \
ca-certificates \
curl \
git \
jq
RUN curl -L -o /usr/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/v1.13.0/bin/linux/amd64/kubectl && \
chmod +x /usr/bin/kubectl && \
kubectl version --client
COPY dryrun /usr/bin/dryrun
CMD ["dryrun"]
如上所示,只需要一个 Dockerfile,工作原理和 docker 类似。Cmd dryrun 在这里是复制的 bash 脚本:
#!/bin/bash
main(){
echo ">>>> Action started"
# Decode the secret passed by the action and paste the config in a file.
echo $KUBECONFIG | base64 -d > ./kubeconfig.yaml
echo ">>>> kubeconfig created"
# Check if the kubernetes directory has change
diff=$(git diff --exit-code HEAD~1 HEAD ./kubernetes)
if [ $? -eq 1 ]; then
echo ">>>> Detected a change inside the kubernetes directory"
# Apply the changes with --dryrun just to validate them
kubectl apply --kubeconfig ./kubeconfig.yaml --dry-run -f ./kubernetes
else
echo ">>>> No changed detected inside the ./kubernetes folder. Nothing to do."
fi
}
main "$@"
第二个操作和此几乎一样,Dockerfile 是相同的,但 CMD 看起来是这样的:
#!/bin/bash
main(){
# Decode the secret passed by the action and paste the config in a file.
echo $KUBECONFIG | base64 -d > ./kubeconfig.yaml
# Check if it is an event generated by the PR is a merge
merged=$(jq --raw-output .pull_request.merged "$GITHUB_EVENT_PATH")
# Retrieve the base branch for the PR because I would like to apply only PR merged to master
baseRef=$(jq --raw-output .pull_request.base.ref "$GITHUB_EVENT_PATH")
if [[ "$merged" == "true" ]] && [[ "$baseRef" == "master" ]]; then
echo ">>>> PR merged into master. Shipping to k8s!"
kubectl apply --kubeconfig ./kubeconfig.yaml -f ./kubernetes
else
echo ">>>> Nothing to do here!"
fi
}
main "$@"
除此之外,工作流文件还有一个生成器,似乎效果不错。secrets 允许开箱即用,并与第三方服务集成,也可用 bash 做任何想做的事情!
参考链接:https://gianarb.it/blog/kubernetes-github-action
更多内容推荐
深入理解 Kubernetes Operator
Kubernetes Operator对于想要简化应用程序的开发人员或降低系统复杂性的DevOps工程师来说都是一个很有吸引力的选择。本文将介绍如何从头开始创建Operator。
如何管理云原生应用程序的依赖关系
向云端迁移可能也是一项非常艰巨的任务。
40|命令式和声明式,谁才是驱动云原生的“引擎”?
这节课我们来聊聊命令式和声明式。
2023-03-10
K8S CronJob 简单入门,和手动重复操作 Say Goodbye!
有时,调度一个应用程序进程、一些重复的操作(如发送邮件、告警、验证等)是极为必要的。
使用 Argo CD 和 Vault 实现安全的 GitOps
在这篇文章中,我们将在AWS中建立一个K3s Kubernetes集群,然后使用Argo CD和Vault实现安全的GitOps。
容器编排器生态:Swarm、Kubernetes、Nomad 并非仅有产品,但是最有生命力三个
容器编排领域可能还会出现许多令人兴奋的新想法和新发展。
2. 镜像安全
2023-09-27
每天部署数千个容器实例,扩缩容复杂性该如何管理?
无论是大型软件公司还是小型软件公司,现在每天都要部署数千个容器实例,这种扩缩容的复杂性是他们必须要管理的。本文介绍了如何将 Kubernetes 纳入到现有的传统 CI/CD 管道中,并实现服务的高可用性,以及随时在生产环境中进行代码变更。
避免不完全的云原生(四):技术和基础设施角度
虽然我们在前两篇文章中讨论的人员、流程、架构和设计问题都是云原生解决方案的关键推动因素,但云原生解决方案最终要落在技术和基础设施上,这也是我们在本文中要讨论的内容。
如何将你的 Python 项目全面自动化?
手把手教你构建和全方位自动化一个Python项目。
2. 容器 Serverless
2023-09-27
Argo CD 使用指南:如何构建一套完整的 GitOps?
随着Kubernetes将自己确立为容器编排的行业标准,为你的应用和工具找到使用声明式模型的有效方法是成功的关键。
解放开发者!3 款工具实现快速 K8S 开发
在这篇文章中,我们将探讨开发人员如何使用DevSpace和Rancher来简化Kubernetes开发。
31|项目实战与部署:如何实现接口部署与访问?
在企业应用当中,把项目部署到服务器上,不但能让前端访问接口,也能供更多用户使用我们的平台。
2023-07-03
5. 基于 Kubeadm 及 Kubespray 安装高可用集群
2023-09-26
使用 Strimzi 将 Kafka 和 Debezium 迁移到 Kubernetes
将Kafka集群部署到Kubernetes中并不是一件容易的事。
记录我们迁移到 Docker 的挑战和经验教训
本文深入讨论了在迁移到Docker的过程中所面临的挑战和我们学到的经验教训。
K8S CSI 容器存储接口 (一):介绍以及原理
容器存储接口(CSI)是用于将任意块和文件存储系统暴露给诸如Kubernetes之类的容器编排系统(CO)上的容器化工作负载的标准。 使用CSI的第三方存储提供商可以编写和部署在Kubernetes中公开新存储系统的插件,而无需接触核心的Kubernetes代码。
2020-11-26
加速 Kubernetes 部署的最佳实践
在本文中,我们将介绍扩展Pod、副本控制器(Replication Controller),以及加速Kubernetes 部署(Deployment)的最佳实践。
35|秒级开发体验,如何实现容器热加载和一键调试?
这节课,我们来学习如何借助 Nocalhost 实现 Kubernetes 应用秒级的开发体验,提升开发循环反馈效率。
2023-02-27
InfoQ 主编
推荐阅读
现代初创公司的架构:取决于团队的成熟度
混沌工程新视角:利用 eBPF 技术改进云原生可观察性与安全性
云安全11-FastDFS 部署与使用
2023-09-28
容器与无服务器,是竞争对手还是队友?
6.Docker-compose
2023-09-30
33|环境:基于 GraalVM 的 JVM 云原生环境搭建
2023-11-13
如何用 Go 语言构建、测试和部署可扩展的 REST API
电子书
大厂实战PPT下载
换一换 王平 | 携程 资深后端开发专家
王一男 | 腾讯 DevOps产品专家
阮坤良 | 腾讯科技 高级开发工程师
评论