Writing Docker program for Java services

-

Docker --

download docker and install in local machine


download Jenkins - 


  • To use the latest LTS: docker pull jenkins/jenkins:lts-jdk11
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure jenkins/jenkins:lts-jdk11


Jenkins initial setup is required. An admin user has been created and a password generated.

Please use the following password to proceed to installation:

b7ae63fb5e4c4cfc9746903abc1adf2d

This may also be found at: /var/jenkins_home/secrets/initialAdminPassword


admin/admin => jenkin started 


Maven Phases

Although hardly a comprehensive list, these are the most common default lifecycle phases executed.

  • validate: validate the project is correct and all necessary information is available
  • compile: compile the source code of the project
  • test: test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
  • package: take the compiled code and package it in its distributable format, such as a JAR.
  • integration-test: process and deploy the package if necessary into an environment where integration tests can be run
  • verify: run any checks to verify the package is valid and meets quality criteria
  • install: install the package into the local repository, for use as a dependency in other projects locally
  • deploy: done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

There are two other Maven lifecycles of note beyond the default list above. They are

  • clean: cleans up artifacts created by prior builds
  • site: generates site documentation for this project

----------------------------------

Provides advanced editor and runtime support for Kubernetes.

Features:

Cluster interaction

Browsing cluster objects, extracting and editing their configurations, describing them

Viewing events

Viewing and downloading pod logs

Attaching pod console

Running shell in pod

Forwarding ports to pod

Applying resource YAML configurations from the editor

Deleting resources from cluster

Completion of ConfigMap/Secret entries from the cluster

Configuring path to kubectl

Configuring custom kubeconfig files globally and per project

Switching contexts and namespaces

Using API schema (including CRD) from the active cluster for editing resource manifests

Editing resource configurations (API 1.6 - 1.28)

Rich YAML support

Auto-completion of keys/values/resource kinds/API versions

"Deep" key auto-completion: invoke Smart Completion when you type -- matching keys from all levels below will be offered

Quick documentation

Detection of invalid/missing/duplicated keys

Detection of non-editable (read only) keys and resources

Detection of deprecated keys and resources

Completion/navigation/find usages/rename of Kubernetes meta-information labels

Completion/navigation/find usages/rename of ConfigMap/Secret entries

Quick jump to matching selector targets and back

Docker image completion (powered by JetBrains Docker plugin)

Enhancements for original Kubernetes model (enums instead of plain strings where applicable)

Support for editing Helm templates

Helm 2.x/3.x file structure/schema support

Go Template syntax support (powered by JetBrains Go Template plugin)

Object values auto-completion/navigation/rename/inspections

Named templates auto-completion/navigation/rename/inspections

Dependency name/version/repository auto-completion

Template result preview

External tgz dependencies content browsing in the project tree

Limited editor support for Werf (https://werf.io) templates and werf.yaml

Quick documentation

validation of values.yaml by values.schema.json (powered by JetBrains JSON plugin)

Useful actions: lint, update dependencies, create chart, create dependency, add repository, convert dependencies from Helm 2.x format to Helm 3.x

Editor support for Kustomize configurations (kustomization.yaml)

Fields completion/validation

Local file path completion/validation

Quick documentation

Kustomize version selection (kubectl embedded, standalone)

Kustomize 3.x inline patches editing support (experimental)

Custom resource definition (CRD) support

Custom resources can be validated by providing complementary OpenAPI 2.0 files with CRD schemas and/or CRD resource definitions (YAML) (limited support).

Getting started

Go to View - Tool windows - Services to setup a connection to Kubernetes cluster.



Comments

Post a Comment

Popular posts from this blog

Spark Cluster

-
Image
Spark applications run as independent sets of processes on a cluster, coordinated by the   SparkContext   object in your main program (called the   driver program ). Specifically, to run on a cluster, the SparkContext can connect to several types of  cluster managers  (either Spark’s own standalone cluster manager, Mesos or YARN), which allocate resources across applications. Once connected, Spark acquires  executors  on nodes in the cluster, which are processes that run computations and store data for your application. Next, it sends your application code (defined by JAR or Python files passed to SparkContext) to the executors. Finally, SparkContext sends  tasks  to the executors to run. There are several useful things to note about this architecture: Each application gets its own executor processes, which stay up for the duration of the whole application and run tasks in multiple threads. This has the benefit of isolating applications from ...
Read more

DORA Metrics

-
 DORA metrics, often referred to as the DORA (DevOps Research and Assessment) metrics, are a set of key performance indicators (KPIs) used to measure and assess the effectiveness of an organization's DevOps practices. DORA metrics were developed by the DevOps Research and Assessment team, which includes notable figures in the DevOps community such as Dr. Nicole Forsgren and Jez Humble. The DORA metrics encompass four key areas: 1. **Deployment Frequency:** This metric measures how often an organization deploys code changes to production. Higher deployment frequencies indicate a more agile and responsive development process. 2. **Lead Time for Changes:** This metric tracks the time it takes for code changes to go from code commit to being deployed in production. Shorter lead times suggest efficient and streamlined development and delivery processes. 3. **Mean Time to Recover (MTTR):** MTTR measures how quickly an organization can recover from failures or incidents in production. Low...
Read more