cassandra可视化_容器化Spring Data Cassandra应用程序

cassandra可视化

我正在继续学习Docker的旅程。 在这一点上，我仍然保持简单。 这次，我将解决将Spring和Cassandra应用程序转换为使用容器而不是在主机上本地运行的问题。 更确切地说，使用Spring Data Cassandra整理应用程序。

我希望我前几天看过进行此更改。 我在Cassandra上写了很多文章，每次我必须cd到正确的目录或有启动它的快捷方式时。 我想这没什么大不了的，但是还涉及其他一些事情。 例如，删除和重新创建键空间，以便我可以从头开始测试我的应用程序。 现在，我只删除容器并重新启动它。 无论如何对我来说，这是有帮助的！

这篇文章与我以前的文章《 使用Docker将现有应用程序推送到容器》稍有不同。 取而代之的是，我将更加侧重于应用程序端，并删除仅使用Docker的中间步骤，而是直接跳至Docker Compose。

集装箱集装箱

我认为最好从项目的容器端开始，因为应用程序取决于Cassandra容器的配置。

我们走吧！

FROM openjdk:10-jre-slim
LABEL maintainer="Dan Newton"
ARG JAR_FILE
ADD target/${JAR_FILE} app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]

这里没有太多的事情。 这个Dockerfile构建了Spring应用程序映像，稍后将其放入容器中。

接下来是docker-compose文件。 这将同时构建Spring应用程序和Cassandra容器：

version: '3'
services:
  app:
    build:
      context: .
      args:
        JAR_FILE: /spring-data-cassandra-docker-1.0.0.jar
    restart: always
  cassandra:
image: "cassandra"

同样，这里没有太多。 app容器使用Dockerfile定义的Dockerfile构建Spring应用程序。 相反， cassandra容器依赖于现有的映像，适当地命名为cassandra 。

突出的一件事是restart属性设置为always 。 这是我懒惰的尝试，目的是超越Cassandra启动所需的时间，并且所有容器都以docker-compose开头的事实是同时启动的。 这导致应用程序在未准备就绪的情况下尝试连接到Cassandra的情况。 不幸的是，这导致应用程序崩溃。 我希望它对内置的初始连接将有一些重试功能……但事实并非如此。

当我们遍历代码时，我们将看到如何以编程方式处理初始Cassandra连接，而不是依赖于应用程序死掉并多次重启。 您仍然会看到我处理连接的版本……我不是真正的解决方案拥护者，但是我尝试的所有其他操作都使我更加痛苦。

一点代码

我说这篇文章将把重点更多地放在应用程序代码上，但是我们不会深入研究我在此应用程序中放置的所有内容以及如何使用Cassandra。 有关此类