问题标签 [jib]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
google-cloud-platform - Jib - Google Container Registry:无法通过错误“无法解析 json 密钥”向注册表进行身份验证
我想将我的图像推送到谷歌的容器注册表。
我正在使用的命令是(通过 Gitlab Ci 执行,变量正在工作,提前一个阶段对其进行测试):
服务帐户的权限是“存储对象管理”。
错误:(顺便说一句:Spring Boot 应用程序正在运行 - 在前面的阶段进行测试)
作为密码,除了json文件之外,我还尝试直接解析以'MIIEv ...'开头的密钥。(没有 \n 和 ---BEGIN/END----)
我真的希望有人可以帮助我解决这个问题。
gitlab - 无法推送到 Gitlab 注册表 | Quarkus - 吊臂构建
我目前正在开发 Quarkus 应用程序,因此需要一个 CI 管道 + 容器注册表。
由于通过 docker 的容器化不起作用(docker daemon - 特权模式),我想使用 Quarkus 已经支持的 Jib。
管道中的命令:
- 用户名 = 部署令牌用户名
- 密码 = 部署令牌
部署令牌具有所有权限,因此这不应该是问题。
我还尝试了在注册表 url 中添加令牌的命令的不同变体:
- https://username:token@registry.gitlab.com(group)/(project)
- https://name:token@registry.gitlab.com(group)/(project)
但在那些没有这些参数的情况下很明显:
- Dquarkus.container-image.username=$用户名
- Dquarkus.container-image.password=$deployToken
但我每次都得到同样的回应:
我真的希望有人有一个想法,这里出了什么问题。
在另一个项目中,我还使用 Jib 将 Spring Boot 应用程序容器化并将其推送到 Google Container Registry,当我提前使用 Google SDK 时,它可以工作。
Gitlab Registry 可能有类似的方法吗?
java - gcr.io/distroless/java:11 使用从 11:.0.6 到 11.0.8 的基本版本
在 distroless java docker image 中更改次要版本。
当前的 java 项目使用 maven jib 来构建 docker 镜像。docker 映像的默认版本是 java 11。此 docker 映像的次要 java 版本设置为 11.0.6。
如何将此映像 gcr.io/distroless/java:11 的 Java 次要版本从 11.0.6 更改为更高版本。
spring-boot - spring-boot:build-image 与 jib 有什么区别?
Spring Boot 2.3.x 添加了通过 spring-boot:build-image 使用其插件构建 Docker 映像的功能。Jib 似乎允许相同的功能,但不限于 Spring boot。
是否有 Spring Boot 应用程序利用该 jib 没有提供的任何特定优化(这就是为什么有一个 Spring Boot 插件的原因?)
除了无法将引导映像与私有注册表一起使用之外。
docker - Jib:如何在不安装的情况下使用 amazon-ecr-credential-helper?
当使用jib-gradle-plugin构建并推送到 AWS ECR 时,它需要我安装aws ecr credential helper,否则构建会报错“系统没有 docker-credential-ecr-login CLI”。
我想知道是否有一种方法可以在不安装凭证帮助程序的情况下推送到 AWS ECR,或者是否可以在存储库中捆绑便携式版本的凭证帮助程序?
安装助手的问题是:
- 它需要在需要构建项目的每台机器上安装助手,因此使构建流程不像我想要的那样自动化
- 要安装 aws ecr 凭证帮助程序,它需要安装 Docker。这感觉有点讽刺,因为 Jib 的很大一部分意义在于构建发生的主机上不需要 Docker,因此构建可以是独立的和可移植的。
我知道这不是 Jib 问题,但我只是希望使用 Jib 的人可能会遇到类似的挑战,因此可以提供一些关于如何解决它的见解。
java - 记录需要 ASM8
我想使用具有预览功能的最新 Java 15。我正在使用 Spring Boot 2.4.0-M2 和 Gradle 6.7-rc2,它们都支持 Java 15 功能。
我想使用 jib 从我的项目中构建一个 docker 映像。这是我的吊臂配置:
不幸的是,当我运行时,./gradlew jib
我收到以下错误:
这是使用--info
标志运行时的输出:
有没有人遇到过类似的问题?
java - Jib maven 插件如何在不使用 docker 守护进程的情况下构建图像?
在过去的几个月里,我一直在试验 docker,并享受了在容器中构建和运行 java 应用程序的好处。
几周前,我偶然发现了jib maven 插件,并注意到 jib 可以在不使用 docker daemon 的情况下将映像构建到 docker 注册表。
在将 jib 添加到我的一个项目并运行后mvn clean install jib:build
(在没有安装 docker 的 VM 上),我很惊讶 jib 实际构建了包含我的项目的图像并将其推送到远程注册表。
出于好奇,我上网阅读了有关 jib 如何在没有安装 docker 的情况下构建和推送 docker 映像的更多信息,但几乎没有找到关于该主题的信息。我设法找到了一篇文章,它解释了几种不使用 docker 创建图像的方法,并且还试图jib:build
通过阅读它的源代码来理解 maven 目标是如何工作的,但是两者都没有让我对运行时场景背后发生的事情有任何见解jib:build
.
如果有人分享更多关于 jib maven 插件以及它如何在不使用 docker 守护进程的情况下在幕后实际构建和推送图像的信息,我将不胜感激。
java - Google JIB 创建的 Docker Image 不包含 spring rest docs 的 asciidoc
我使用 Spring Rest Docs 和 JIB
当我这样做./gradlew build
时java -jar /some/build/libs/app.jar
。我可以在example.com/docs/asciidocname.html
.
但 docker 图像./gradlew jib
不包含此 url。
我想获得由 Spring Rest Docs 生成的 Api 文档,当我这样做时./gradlew jib
以下是我的一部分build.gradle
openshift - Spring Boot 应用程序(JHipster)和 Keycloak 之间通过 HTTPS 的通信问题
在我的团队中,我们正在尝试在 OpenShift (4.2) 上部署基于 JHipster (6.8.0) 的微服务堆栈。
我们目前在网关启动并尝试通过 HTTPS 与 Keycloak 通信时遇到问题(准确地说,使用基于 Keycloak 的 Red Hat Single Sign On 7.3)。
这是引发的异常:
我们认为这是因为我们的网关不信任来自 Keycloak 的证书。确实,这是使用组织证书。我们已经登录到网关尝试连接的领域的 Keycloak 管理界面。我们已将证书提取为 X.509 二进制编码的 DER 文件;感谢 Chrome 浏览器功能。
我们首先尝试简单地将这些证书添加到etc/ssl/certs/java/cacerts
网关容器的文件夹中。为此,我们在项目 jib 存储库中创建了这些文件夹src/main/jib/etc/ssl/certs/java/cacerts
,并将证书复制到其中。
我们已经使用 Maven 和jib:dockerBuild
选项生成了网关 Docker 映像。我们将它推送到我们的 Docker 注册表并将其部署到 OpenShift。检查 OpenShift pod 后,证书已在etc/ssl/certs/java/cacerts
. 但是我们仍然得到与以前相同的错误。
然后我们尝试使用信任库。因此,我们使用以下命令为每个证书创建了一个:
由于以下命令,我们检查了所有证书是否已正确添加:
然后我们将此 applicationTrustStore.jks 文件添加到 src/main/jib/etc/ssl/certs/java/cacerts
我们项目的文件夹中,并将其添加到 pom.xml 中:
再一次,我们生成并重新部署到 OpenShift,但没有成功;仍然是完全相同的问题。
我们当然遗漏了一些明显的东西,但我们不能指望它。