在 openshift 中初始化容器
Init container in openshift
我是 openshift 的新手,我浏览了 Openshift 网站了解更多详细信息,但想知道是否有人部署了 init 容器。
我想用它从数据库中获取转储并在 init 容器的帮助下将其恢复到新版本
我们正在使用 postgres 数据库
如有任何帮助,我们将不胜感激。
谢谢!
I want to use that to take dump from database and restore it to new version of it with the help of init container
我会说你应该使用运算符而不是 initContainer。看看下面Init Containers Design Considerations
创建 initcontainer 时应考虑一些注意事项:
- 它们总是在 Pod 中的其他容器之前执行。所以他们
不应包含需要很长时间才能完成的复杂逻辑。
启动脚本通常小而简洁。如果你发现
你在初始化容器中添加了太多逻辑,你应该考虑
将它的一部分移动到应用程序容器本身。
- Init 容器按顺序启动和执行。一个初始化
除非容器的前身完成,否则不会调用容器
成功地。因此,如果启动任务很长,你可以
考虑将其分解为多个步骤,每个步骤由一个 init 处理
容器,以便您知道哪些步骤失败了。
- 如果任何一个init容器失败,整个Pod都会重启
(除非您将 restartPolicy 设置为 Never)。重启 Pod 意味着
re-executing 所有容器再次包括任何初始容器。
因此,您可能需要确保启动逻辑容忍
多次执行而不会导致重复。例如,如果
数据库迁移已经完成,再次执行迁移命令
应该被忽略。
- init 容器是延迟应用程序的理想选择
初始化直到一个或多个依赖项可用。为了
例如,如果您的应用程序依赖于强加 API 的 API
request-rate限制,可能需要等待一定时间
能够收到来自 API 的回复。实现这个逻辑
在应用程序容器中可能很复杂;因为它需要
结合健康和就绪探测器。一个更简单的方法是
正在创建一个等待 API 准备就绪的初始化容器
在它成功退出之前。应用程序容器将启动
只有在 init 容器成功完成它的工作之后。
- Init 容器不能将运行状况和就绪探测用作应用程序
容器做。原因是它们意味着开始和退出
成功,就像乔布斯和 CronJobs 的行为一样。
- 同一 Pod 上的所有容器共享相同的卷和网络。
您可以利用此功能在用户之间共享数据
应用程序及其初始容器。
关于使用它转储数据,我发现的唯一一件事是 example 关于用 mysql 做的,也许它可以指导你如何用 postgresql 做它。
In this scenario, we are serving a MySQL database. This database is used for testing an application. It doesn’t have to contain real data, but it must be seeded with enough data so that we can test the application's query speed. We use an init container to handle downloading the SQL dump file and restore it to the database, which is hosted in another container. This scenario can be illustrated as below:
The definition file may look like this:
apiVersion: v1
kind: Pod
metadata:
name: mydb
labels:
app: db
spec:
initContainers:
- name: fetch
image: mwendler/wget
command: ["wget","--no-check-certificate","https://sample-videos.com/sql/Sample-SQL-File-1000rows.sql","-O","/docker-entrypoint-initdb.d/dump.sql"]
volumeMounts:
- mountPath: /docker-entrypoint-initdb.d
name: dump
containers:
- name: mysql
image: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: "example"
volumeMounts:
- mountPath: /docker-entrypoint-initdb.d
name: dump
volumes:
- emptyDir: {}
name: dump
The above definition creates a Pod that hosts two containers: the init container and the application one. Let’s have a look at the interesting aspects of this definition:
The init container is responsible for downloading the SQL file that contains the database dump. We use the mwendler/wget image because we only need the wget command.
The destination directory for the downloaded SQL is the directory used by the MySQL image to execute SQL files (/docker-entrypoint-initdb.d). This behavior is built into the MySQL image that we use in the application container.
The init container mounts /docker-entrypoint-initdb.d to an emptyDir volume. Because both containers are hosted on the same Pod, they share the same volume. So, the database container has access to the SQL file placed on the emptyDir volume.
此外,对于最佳实践,我建议看一下 kubernetes 运算符,据我所知,这是在 kubernetes 中管理数据库的最佳实践方法。
如果您不熟悉运算符,我建议您从 youtube 上的 kubernetes documentation and this short video 开始。
Operators 是打包 Kubernetes 的方法,使您能够更轻松地管理和监控有状态的应用程序。已有许多运算符可用,例如
它通过提供保持 PostgreSQL 集群正常运行和 运行.
所需的基本功能,自动化和简化在 Kubernetes 上部署和管理开源 PostgreSQL 集群
我是 openshift 的新手,我浏览了 Openshift 网站了解更多详细信息,但想知道是否有人部署了 init 容器。 我想用它从数据库中获取转储并在 init 容器的帮助下将其恢复到新版本 我们正在使用 postgres 数据库
如有任何帮助,我们将不胜感激。
谢谢!
I want to use that to take dump from database and restore it to new version of it with the help of init container
我会说你应该使用运算符而不是 initContainer。看看下面Init Containers Design Considerations
创建 initcontainer 时应考虑一些注意事项:
- 它们总是在 Pod 中的其他容器之前执行。所以他们 不应包含需要很长时间才能完成的复杂逻辑。 启动脚本通常小而简洁。如果你发现 你在初始化容器中添加了太多逻辑,你应该考虑 将它的一部分移动到应用程序容器本身。
- Init 容器按顺序启动和执行。一个初始化 除非容器的前身完成,否则不会调用容器 成功地。因此,如果启动任务很长,你可以 考虑将其分解为多个步骤,每个步骤由一个 init 处理 容器,以便您知道哪些步骤失败了。
- 如果任何一个init容器失败,整个Pod都会重启 (除非您将 restartPolicy 设置为 Never)。重启 Pod 意味着 re-executing 所有容器再次包括任何初始容器。 因此,您可能需要确保启动逻辑容忍 多次执行而不会导致重复。例如,如果 数据库迁移已经完成,再次执行迁移命令 应该被忽略。
- init 容器是延迟应用程序的理想选择 初始化直到一个或多个依赖项可用。为了 例如,如果您的应用程序依赖于强加 API 的 API request-rate限制,可能需要等待一定时间 能够收到来自 API 的回复。实现这个逻辑 在应用程序容器中可能很复杂;因为它需要 结合健康和就绪探测器。一个更简单的方法是 正在创建一个等待 API 准备就绪的初始化容器 在它成功退出之前。应用程序容器将启动 只有在 init 容器成功完成它的工作之后。
- Init 容器不能将运行状况和就绪探测用作应用程序 容器做。原因是它们意味着开始和退出 成功,就像乔布斯和 CronJobs 的行为一样。
- 同一 Pod 上的所有容器共享相同的卷和网络。 您可以利用此功能在用户之间共享数据 应用程序及其初始容器。
关于使用它转储数据,我发现的唯一一件事是 example 关于用 mysql 做的,也许它可以指导你如何用 postgresql 做它。
In this scenario, we are serving a MySQL database. This database is used for testing an application. It doesn’t have to contain real data, but it must be seeded with enough data so that we can test the application's query speed. We use an init container to handle downloading the SQL dump file and restore it to the database, which is hosted in another container. This scenario can be illustrated as below:
The definition file may look like this:
apiVersion: v1
kind: Pod
metadata:
name: mydb
labels:
app: db
spec:
initContainers:
- name: fetch
image: mwendler/wget
command: ["wget","--no-check-certificate","https://sample-videos.com/sql/Sample-SQL-File-1000rows.sql","-O","/docker-entrypoint-initdb.d/dump.sql"]
volumeMounts:
- mountPath: /docker-entrypoint-initdb.d
name: dump
containers:
- name: mysql
image: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: "example"
volumeMounts:
- mountPath: /docker-entrypoint-initdb.d
name: dump
volumes:
- emptyDir: {}
name: dump
The above definition creates a Pod that hosts two containers: the init container and the application one. Let’s have a look at the interesting aspects of this definition:
The init container is responsible for downloading the SQL file that contains the database dump. We use the mwendler/wget image because we only need the wget command. The destination directory for the downloaded SQL is the directory used by the MySQL image to execute SQL files (/docker-entrypoint-initdb.d). This behavior is built into the MySQL image that we use in the application container. The init container mounts /docker-entrypoint-initdb.d to an emptyDir volume. Because both containers are hosted on the same Pod, they share the same volume. So, the database container has access to the SQL file placed on the emptyDir volume.
此外,对于最佳实践,我建议看一下 kubernetes 运算符,据我所知,这是在 kubernetes 中管理数据库的最佳实践方法。
如果您不熟悉运算符,我建议您从 youtube 上的 kubernetes documentation and this short video 开始。
Operators 是打包 Kubernetes 的方法,使您能够更轻松地管理和监控有状态的应用程序。已有许多运算符可用,例如
它通过提供保持 PostgreSQL 集群正常运行和 运行.
所需的基本功能,自动化和简化在 Kubernetes 上部署和管理开源 PostgreSQL 集群