<@UFT11FKSP> We are getting ready to use KVision f...

# kvision

[ashmelev]

@Robert Jaros We are getting ready to use KVision for a production application for a customer. The customer requires containerized deployment (i.e. Docker containers in Kubernetes). Historically we have deployed SpringBoot into a container (built by Google Jib - if you've not tried it, you should have a look, it's a great time-saver) and deployed the React UI as a static WebPak in AWS S3/CloudFront. However, for deploying KVision I think we should use two Jib-built Docker containers (one for front-end and one for back-end) - as it would likely simplify deployment and improve scalability.

Do you have any experience with deploying KVision as two containers? If not, I am happy to work it out and contribute an example - perhaps with some direction from you 🙂

[Robert Jaros]

Not really in containers, but I've deployed fullstack KVision application (with spring boot) separately on two servers - one for the frontend and second for the backend. The configuration should be very similar.

[ashmelev]

I agree. I'm just working through where to add the Google Jib directives in the Gradle build file

[ashmelev]

In principle it should be trivial and two containers would end up in distinct repos. After that it's just Kubernetes "service" plumbing

[Robert Jaros]

When deploying the frontend and the backend apps separately, you need to tell the frontend how to connect to the backend endpoints. By default it will connect to /kv/* endpoints on the same host/domain.

[Robert Jaros]

There is an undocumented option that can be used to easily redirect all frontend calls to the correct URL. You can add:

<script>window["kv_remote_url_prefix"]="<https://any.host.com/any_prefix>";</script>

to the frontend index.html before including main.bundle.js.

[ashmelev]

Understood. In Kubernetes the "service identifier" stands in for the host/domain and the endpoints would stay stable. I'll have to analyze the SpringSecurity issues and see if I have to make any alterations there - not sure if there are any edge cases yet

[Robert Jaros]

Since those will be ajax cross domain calls, you need to enable CORS support on the backend.

[ashmelev]

The front-end re-direction looks interesting, but I think the Kubernetes ingress operator (essentially and NGinX instance) would handle that and anything internal to the cluster would simply call http//<service>/index.html to get the front end

[ashmelev]

I think that the front and back-end would be seeing the same "effective domain" inside the cluster. Inside Kubernetes everything resolves to <service-name>.svc.cluster.local so the "domain" would always appear to be cluster.local

[ashmelev]

Still, good advice on the CORS.... I don't think it'll be an issue as the ingress/NGinX fields that

[ashmelev]

I'll putter around with it in the coming few days and let you know what I discover. It's a popular deployment pattern these days... perhaps someone else will find it useful as well

[jschneider]

I am deploying a a Kvision app using Jib-Cli
Unfortunately I did not find a good way to use "jib" itself. Jib is only really useful for Java applications.

[jschneider]

tasks.create<Exec>("jib") {
  description = "Create the docker image using Jib"
  group = "docker"
  dependsOn("build")

  val target = "[addyourownimage]:$branch"

  val command = mutableListOf(jibCli, "build", "--target=$target", "--build-file=src/main/docker/jib.yaml", "--parameter=gitCommitDate=$gitCommitDate", "--context=.", "--verbosity=info", "--stacktrace", "--http-trace")

  System.getenv("DOCKER_REGISTRY_PASS")?.let {
    command.add("--to-username=[MYUSERNAME]")
    command.add("--to-password=${it}")
  }

  commandLine(command)
  workingDir = project.projectDir
}

[jschneider]

jibCli is a file to the locally installed jib-cli executable

[ashmelev]

@jschneider Ahhh, very nice. Thank you