How to Kubernetes Migration Made Simple with Konveyor Move2Kube

Konveyor accelerates the process of replatforming to Kubernetes by analyzing source artifacts.

Konveyor Move2Kube assists developers in migrating projects from platforms such as Cloud Foundry and Docker swarm to Kubernetes and OpenShift. Move2Kube analyzes your application's source code and generates Infrastructure-as-Code (IaC) artifacts such as Kubernetes YAMLs, Helm charts, Tekton pipelines, and so on.

(Mehant Kammakomati, CC BY-SA 4.0)

Powering Move2Kube is a transformer framework that enables multiple small transformers to be chained together to transform the artifacts completely.

(Mehant Kammakomati, CC BY-SA 4.0)

Many different transformers get involved when transforming a Java or Node.js project to create all the destination artifacts. This allows for the reuse of transformers in various end-to-end flows. Each transformer is capable of performing multiple activities.

(Mehant Kammakomati, CC BY-SA 4.0)

Move2Kube

You can use Move2Kube as a terminal command or as a web app. Its core functionality includes planning and transformation. In the planning phase, Move2Kube analyzes artifacts to identify the services involved. In the transformation phase, it transforms those services into destination artifacts.

The terminal command is a single binary, which you can download and install. Move2Kube also provides a helper script to download and place the binary in your local filesystem:

curl \ https://raw.githubusercontent.com/konveyor/move2kube/main/scripts/install.sh \

-o move2kube_install.sh

Look through the script to ensure its install method aligns with your preference, and then run it:

$ sh ./move2kube_install.sh

To use the command, just run it on a directory containing the application source code:

$ move2kube transform -s ./src

Transform an enterprise scale application

Move2Kube can be used to replatform a real-world enterprise application. There's a demo enterprise app included in the Move2Kube git repository to demonstrate the workflow. This demo app is similar to a typical real-world application with CRUD operations and a multi-tier architecture.

To try it out, download the source code for the enterprise app:

$ curl https://move2kube.konveyor.io/scripts/download.sh \
| bash -s -- -d samples/enterprise-app/src -r move2kube-demos

The source code for the enterprise app is in the src directory.

First, use the move2kube transform command:

$ move2kube transform -s ./src

After running the command, look in the myproject folder. There are new directories, including deploy, scripts, and source. The deploy directory contains all IaC artifacts, such as Kubernetes YAML files, Tekton pipelines, Helm charts, Knative files, compose files, and OpenShift files. The scripts directory contains shell scripts to build and push container images to the registry of your choice. Finally, the source directory contains the source code and Dockerfiles.

Capabilities provided by Move2Kube

Move2Kube has a powerful QA Engine. Transformers can get input from a user using this engine. Transformers receive the input as user interaction through a terminal, a web interface, a REST API, or as a configuration file.

For instance, in the demo enterprise app, the Move2Kube QA engine might ask which port the frontend app should listen on, which container registry should be used to store images, or what ingress host should be used.

To run an app in a non-interactive mode, use the --qa-skip flag. This option causes Move2Kube to use default answers:

$ move2kube transform -s ./src --qa-skip

If you want to answer the questions from a configuration file, use the -f option:

$ move2kube transform -s ./src -f ./m2kconfig.yaml

A list of all answers used for the run is captured as a config in the m2kconfig.yaml file.

Customization capability

Move2Kube includes several transformers ready for use, and it allows users to write new transformers. Move2Kube exposes all the internal transformers' capabilities to be leveraged for writing custom transformers. These capabilities include a QA engine, extensive templating enabled by Golang templates, and isolation. Custom transformers behave exactly the same as built-in transformers. The two types can be chained together to achieve an end-to-end transformation.

Move2Kube generates artifacts you can customize to comply with organizational best practices and policies. You can direct the Move2Kube tool to customizations using the -c or --customization option.

You can create customizations using three different methods:

1. Configure built-in transformers: Configure a built-in transformer to behave differently. For example, you can modify the parameterization transformer to parameterize different values depending on the organization's needs.
2. Starlark-based transformers: Write a complete transformer in a Python-like language, Starlark. For example, you could use a Starlark-based transformer to add custom annotations to Kubernetes YAML files.
3. Executable transformers: Write a complete transformer in a language of your choice and allow Move2Kube to execute it along with the other transformers. For example, generate custom Helm charts to add custom files and directories in specific locations.

Parameterization and customization capability

Move2Kube allows users to parameterize custom fields in the target platform artifacts, such as Helm charts. For instance, parameterizing the number of replicas in a Helm chart:

apiVersion: apps/v1
kind: Deployment
metadata:
    annotations:
        move2kube.konveyor.io/service.expose: "true"
    creationTimestamp: null
    labels:
        move2kube.konveyor.io/service: orders
    name: orders 
spec:
    progressDeadlineSeconds: 600
    replicas: {{ index .Values "common" "replicas" }}

Move2Kube also allows you to customize output artifacts. For instance, add a custom annotation to the Ingress YAML file:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
   annotations:
      kubernetes.io/ingress.class: haproxy
    creationTimestamp: null
    labels:
      move2kube.konveyor.io/service: myproject
    name: myproject

Move2Kube case studies

Mov2Kube has been widely adopted in the industry and open-source communities. Here are some case studies where replatforming using Move2Kube has shown considerable improvement over manual effort.

• InsApp
  • Language Stack: Java (springboot), Angular JS UI
  • Source Platform: Docker Swarm
  • Number of Services: 100
  • Manual Effort: 56 days
  • Move2Kube Effort: 6 days
  • In-Built Transformers Invoked: 6
  • Number of External Transformers: 0
• AA case study
  • Language Stack: Java (springboot), Angular JS UI
  • Source Platform: Cloud-foundary
  • Number of Services: 3
  • Manual Effort: 2 days
  • Move2Kube Effort: 15 minutes
  • In-Built Transformers Invoked: 14
  • Number of External Transformers: 0
• CP case study
  • Language Stack: Python
  • Source Platform: ECS Fargate
  • Number of Services: 7
  • Manual Effort: 12 days
  • Move2Kube Effort: 1 day
  • In-Built Transformers Invoked: 13
  • Number of External Transformers: 0
• MFA case study
  • Language Stack: .NET Silverlight UI
  • Source Platform: Bare-metal/VM
  • Number of Services: 4
  • Manual Effort: 9 days
  • Move2Kube Effort: 5 hours
  • In-Built Transformers Invoked: 14
  • Number of External Transformers: 1 (custom dependencies)
• TMP case study
  • Language Stack: Java (springboot)
  • Source Platform: Cloud-foundry
  • Number of Services: 24
  • Manual Effort: 25 days
  • Move2Kube Effort: 2.25 days
  • In-Built Transformers Invoked: 15
  • Number of External Transformers: 1 (custom directories)

Data source: Seshadri, Padmanabha V., Harikrishnan Balagopal, Akash Nayak, Ashok Pon Kumar, and Pablo Loyola. "Konveyor Move2Kube: A Framework For Automated Application Replatforming." In 2022 IEEE 15th International Conference on Cloud Computing (CLOUD), pp. 115-124. IEEE, 2022.

Learn more about Konveyor Move2Kube

Visit the Move2Kube site to learn more about replatforming using Konveyor Move2Kube.

Original article source at: https://opensource.com/

#kubernetes #simple 

What is GEEK

Buddha Community

50+ Useful Kubernetes Tools for 2020 - Part 2

Introduction

Last year, we provided a list of Kubernetes tools that proved so popular we have decided to curate another list of some useful additions for working with the platform—among which are many tools that we personally use here at Caylent. Check out the original tools list here in case you missed it.

According to a recent survey done by Stackrox, the dominance Kubernetes enjoys in the market continues to be reinforced, with 86% of respondents using it for container orchestration.

(State of Kubernetes and Container Security, 2020)

And as you can see below, more and more companies are jumping into containerization for their apps. If you’re among them, here are some tools to aid you going forward as Kubernetes continues its rapid growth.

(State of Kubernetes and Container Security, 2020)

#blog #tools #amazon elastic kubernetes service #application security #aws kms #botkube #caylent #cli #container monitoring #container orchestration tools #container security #containers #continuous delivery #continuous deployment #continuous integration #contour #developers #development #developments #draft #eksctl #firewall #gcp #github #harbor #helm #helm charts #helm-2to3 #helm-aws-secret-plugin #helm-docs #helm-operator-get-started #helm-secrets #iam #json #k-rail #k3s #k3sup #k8s #keel.sh #keycloak #kiali #kiam #klum #knative #krew #ksniff #kube #kube-prod-runtime #kube-ps1 #kube-scan #kube-state-metrics #kube2iam #kubeapps #kubebuilder #kubeconfig #kubectl #kubectl-aws-secrets #kubefwd #kubernetes #kubernetes command line tool #kubernetes configuration #kubernetes deployment #kubernetes in development #kubernetes in production #kubernetes ingress #kubernetes interfaces #kubernetes monitoring #kubernetes networking #kubernetes observability #kubernetes plugins #kubernetes secrets #kubernetes security #kubernetes security best practices #kubernetes security vendors #kubernetes service discovery #kubernetic #kubesec #kubeterminal #kubeval #kudo #kuma #microsoft azure key vault #mozilla sops #octant #octarine #open source #palo alto kubernetes security #permission-manager #pgp #rafay #rakess #rancher #rook #secrets operations #serverless function #service mesh #shell-operator #snyk #snyk container #sonobuoy #strongdm #tcpdump #tenkai #testing #tigera #tilt #vert.x #wireshark #yaml

What are the benefits of cloud migration? Reasons you should migrate

The moving of applications, databases and other business elements from the local server to the cloud server called cloud migration. This article will deal with migration techniques, requirement and the benefits of cloud migration.

In simple terms, moving from local to the public cloud server is called cloud migration. Gartner says 17.5% revenue growth as promised in cloud migration and also has a forecast for 2022 as shown in the following image.

#cloud computing services #cloud migration #all #cloud #cloud migration strategy #enterprise cloud migration strategy #business benefits of cloud migration #key benefits of cloud migration #benefits of cloud migration #types of cloud migration

How to Kubernetes Migration Made Simple with Konveyor Move2Kube

Konveyor accelerates the process of replatforming to Kubernetes by analyzing source artifacts.

Konveyor Move2Kube assists developers in migrating projects from platforms such as Cloud Foundry and Docker swarm to Kubernetes and OpenShift. Move2Kube analyzes your application's source code and generates Infrastructure-as-Code (IaC) artifacts such as Kubernetes YAMLs, Helm charts, Tekton pipelines, and so on.

(Mehant Kammakomati, CC BY-SA 4.0)

Powering Move2Kube is a transformer framework that enables multiple small transformers to be chained together to transform the artifacts completely.

(Mehant Kammakomati, CC BY-SA 4.0)

Many different transformers get involved when transforming a Java or Node.js project to create all the destination artifacts. This allows for the reuse of transformers in various end-to-end flows. Each transformer is capable of performing multiple activities.

(Mehant Kammakomati, CC BY-SA 4.0)

Move2Kube

You can use Move2Kube as a terminal command or as a web app. Its core functionality includes planning and transformation. In the planning phase, Move2Kube analyzes artifacts to identify the services involved. In the transformation phase, it transforms those services into destination artifacts.

The terminal command is a single binary, which you can download and install. Move2Kube also provides a helper script to download and place the binary in your local filesystem:

curl \ https://raw.githubusercontent.com/konveyor/move2kube/main/scripts/install.sh \

-o move2kube_install.sh

Look through the script to ensure its install method aligns with your preference, and then run it:

$ sh ./move2kube_install.sh

To use the command, just run it on a directory containing the application source code:

$ move2kube transform -s ./src

Transform an enterprise scale application

Move2Kube can be used to replatform a real-world enterprise application. There's a demo enterprise app included in the Move2Kube git repository to demonstrate the workflow. This demo app is similar to a typical real-world application with CRUD operations and a multi-tier architecture.

To try it out, download the source code for the enterprise app:

$ curl https://move2kube.konveyor.io/scripts/download.sh \
| bash -s -- -d samples/enterprise-app/src -r move2kube-demos

The source code for the enterprise app is in the src directory.

First, use the move2kube transform command:

$ move2kube transform -s ./src

After running the command, look in the myproject folder. There are new directories, including deploy, scripts, and source. The deploy directory contains all IaC artifacts, such as Kubernetes YAML files, Tekton pipelines, Helm charts, Knative files, compose files, and OpenShift files. The scripts directory contains shell scripts to build and push container images to the registry of your choice. Finally, the source directory contains the source code and Dockerfiles.

Capabilities provided by Move2Kube

Move2Kube has a powerful QA Engine. Transformers can get input from a user using this engine. Transformers receive the input as user interaction through a terminal, a web interface, a REST API, or as a configuration file.

For instance, in the demo enterprise app, the Move2Kube QA engine might ask which port the frontend app should listen on, which container registry should be used to store images, or what ingress host should be used.

To run an app in a non-interactive mode, use the --qa-skip flag. This option causes Move2Kube to use default answers:

$ move2kube transform -s ./src --qa-skip

If you want to answer the questions from a configuration file, use the -f option:

$ move2kube transform -s ./src -f ./m2kconfig.yaml

A list of all answers used for the run is captured as a config in the m2kconfig.yaml file.

Customization capability

Move2Kube includes several transformers ready for use, and it allows users to write new transformers. Move2Kube exposes all the internal transformers' capabilities to be leveraged for writing custom transformers. These capabilities include a QA engine, extensive templating enabled by Golang templates, and isolation. Custom transformers behave exactly the same as built-in transformers. The two types can be chained together to achieve an end-to-end transformation.

Move2Kube generates artifacts you can customize to comply with organizational best practices and policies. You can direct the Move2Kube tool to customizations using the -c or --customization option.

You can create customizations using three different methods:

1. Configure built-in transformers: Configure a built-in transformer to behave differently. For example, you can modify the parameterization transformer to parameterize different values depending on the organization's needs.
2. Starlark-based transformers: Write a complete transformer in a Python-like language, Starlark. For example, you could use a Starlark-based transformer to add custom annotations to Kubernetes YAML files.
3. Executable transformers: Write a complete transformer in a language of your choice and allow Move2Kube to execute it along with the other transformers. For example, generate custom Helm charts to add custom files and directories in specific locations.

Parameterization and customization capability

Move2Kube allows users to parameterize custom fields in the target platform artifacts, such as Helm charts. For instance, parameterizing the number of replicas in a Helm chart:

apiVersion: apps/v1
kind: Deployment
metadata:
    annotations:
        move2kube.konveyor.io/service.expose: "true"
    creationTimestamp: null
    labels:
        move2kube.konveyor.io/service: orders
    name: orders 
spec:
    progressDeadlineSeconds: 600
    replicas: {{ index .Values "common" "replicas" }}

Move2Kube also allows you to customize output artifacts. For instance, add a custom annotation to the Ingress YAML file:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
   annotations:
      kubernetes.io/ingress.class: haproxy
    creationTimestamp: null
    labels:
      move2kube.konveyor.io/service: myproject
    name: myproject

Move2Kube case studies

Mov2Kube has been widely adopted in the industry and open-source communities. Here are some case studies where replatforming using Move2Kube has shown considerable improvement over manual effort.

• InsApp
  • Language Stack: Java (springboot), Angular JS UI
  • Source Platform: Docker Swarm
  • Number of Services: 100
  • Manual Effort: 56 days
  • Move2Kube Effort: 6 days
  • In-Built Transformers Invoked: 6
  • Number of External Transformers: 0
• AA case study
  • Language Stack: Java (springboot), Angular JS UI
  • Source Platform: Cloud-foundary
  • Number of Services: 3
  • Manual Effort: 2 days
  • Move2Kube Effort: 15 minutes
  • In-Built Transformers Invoked: 14
  • Number of External Transformers: 0
• CP case study
  • Language Stack: Python
  • Source Platform: ECS Fargate
  • Number of Services: 7
  • Manual Effort: 12 days
  • Move2Kube Effort: 1 day
  • In-Built Transformers Invoked: 13
  • Number of External Transformers: 0
• MFA case study
  • Language Stack: .NET Silverlight UI
  • Source Platform: Bare-metal/VM
  • Number of Services: 4
  • Manual Effort: 9 days
  • Move2Kube Effort: 5 hours
  • In-Built Transformers Invoked: 14
  • Number of External Transformers: 1 (custom dependencies)
• TMP case study
  • Language Stack: Java (springboot)
  • Source Platform: Cloud-foundry
  • Number of Services: 24
  • Manual Effort: 25 days
  • Move2Kube Effort: 2.25 days
  • In-Built Transformers Invoked: 15
  • Number of External Transformers: 1 (custom directories)

Data source: Seshadri, Padmanabha V., Harikrishnan Balagopal, Akash Nayak, Ashok Pon Kumar, and Pablo Loyola. "Konveyor Move2Kube: A Framework For Automated Application Replatforming." In 2022 IEEE 15th International Conference on Cloud Computing (CLOUD), pp. 115-124. IEEE, 2022.

Learn more about Konveyor Move2Kube

Visit the Move2Kube site to learn more about replatforming using Konveyor Move2Kube.

Original article source at: https://opensource.com/

#kubernetes #simple 

Kubernetes in the Cloud: Strategies for Effective Multi Cloud Implementations

Kubernetes is a highly popular container orchestration platform. Multi cloud is a strategy that leverages cloud resources from multiple vendors. Multi cloud strategies have become popular because they help prevent vendor lock-in and enable you to leverage a wide variety of cloud resources. However, multi cloud ecosystems are notoriously difficult to configure and maintain.

This article explains how you can leverage Kubernetes to reduce multi cloud complexities and improve stability, scalability, and velocity.

Kubernetes: Your Multi Cloud Strategy

Maintaining standardized application deployments becomes more challenging as your number of applications and the technologies they are based on increase. As environments, operating systems, and dependencies differ, management and operations require more effort and extensive documentation.

In the past, teams tried to get around these difficulties by creating isolated projects in the data center. Each project, including its configurations and requirements were managed independently. This required accurately predicting performance and the number of users before deployment and taking down applications to update operating systems or applications. There were many chances for error.

Kubernetes can provide an alternative to the old method, enabling teams to deploy applications independent of the environment in containers. This eliminates the need to create resource partitions and enables teams to operate infrastructure as a unified whole.

In particular, Kubernetes makes it easier to deploy a multi cloud strategy since it enables you to abstract away service differences. With Kubernetes deployments you can work from a consistent platform and optimize services and applications according to your business needs.

The Compelling Attributes of Multi Cloud Kubernetes

Multi cloud Kubernetes can provide multiple benefits beyond a single cloud deployment. Below are some of the most notable advantages.

Stability

In addition to the built-in scalability, fault tolerance, and auto-healing features of Kubernetes, multi cloud deployments can provide service redundancy. For example, you can mirror applications or split microservices across vendors. This reduces the risk of a vendor-related outage and enables you to create failovers.

#kubernetes #multicloud-strategy #kubernetes-cluster #kubernetes-top-story #kubernetes-cluster-install #kubernetes-explained #kubernetes-infrastructure #cloud

How to perform migration rollback in laravel

As we know that laravel migration provides very simple way to create database table structure. We need to create migration file and write table structure then migrate that migration. Sometimes we need to rollback that migration. So here we will discuss about the migration rollback in laravel.

We can run the rollback artisan command to rollback on a particular step. We can execute the following artisan command.

php artisan migrate:rollback --step=1

Every time when we will rollback, we will get the last batch of migration.

**Note: **This rollback command will work on laravel 5.3 or above version. For the version below 5.3, there is no command available for migration rollback in laravel.

We can also use the following command to rollback and re migrate.

php artisan migrate:refresh --step=2

It will rollback and remigrate last two migration.

You can also checkout the article for executing single migration by clicking on the link below.

How to migrate single migration in laravel

#laravel #how to perform rollback migration in laravel #laravel migration rollback #migration refresh in laravel #migration rollback batch in laravel #migration rollback for one specific migration #migration rollback in laravel