Azure - Pipeline - Add Approver for Stage

https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops&tabs=check-pass

Azure: Resize VM : How to expand the OS drive of a virtual machine

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/expand-os-disk

https://medium.com/100-days-of-linux/how-to-resize-a-linux-root-file-system-af3e5096b4e4

https://docs.microsoft.com/en-us/azure/virtual-machines/linux/expand-disks

How to debug Azure VM Issues

https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/troubleshoot-recovery-disks-portal-linux

https://www.hiroom2.com/2018/04/30/ubuntu-1804-serial-console-en/#sec-1

https://tldp.org/HOWTO/Remote-Serial-Console-HOWTO/configure-boot-loader-grub.html

https://www.hiroom2.com/2018/04/30/ubuntu-1804-serial-console-en/

https://askubuntu.com/questions/924913/how-to-get-to-the-grub-menu-at-boot-time-using-serial-console

https://www.youtube.com/watch?v=sVMgZ9YW6i8

https://www.lcn.com/support/articles/how-to-show-hidden-files-in-ftp/

https://askubuntu.com/questions/391082/how-to-see-time-stamps-in-bash-history

SSH Not Getting Connected : Azure VM

 Settings   ->  Disks

Settings   ->  Properties  -> Agent status : Not Ready  or Ready

TTY

Sys REQ 

Grub Loader

Serial Console

sysctl -a |grep -i sysrq

https://www.youtube.com/watch?v=KevOc3d_SG4&t=147s

https://www.youtube.com/watch?v=HnvUxnNzbe4

https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-grub-proactive-configuration 

https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html

waagent 

https://github.com/Azure/WALinuxAgent

The Microsoft Azure Linux Agent (waagent) manages Linux provisioning and VM interaction with the Azure Fabric Controller.

What is Azure fabric?

Azure Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices and containers

Operations   ->

Monitoring  ->

Automation  ->

Support + troubleshooting  ->  Resource health

Support + troubleshooting  ->  Boot diagnostics

Support + troubleshooting  ->  Performance diagnostics

Support + troubleshooting  ->  Serial console

Connect -> Connect with Bastion Host 

https://docs.microsoft.com/en-us/azure/bastion/tutorial-create-host-portal

https://www.rebeladmin.com/2019/11/step-step-guide-access-azure-vms-securely-using-azure-bastion/

Role

https://docs.microsoft.com/en-us/azure/role-based-access-control/check-access

Azure VM     ->    Support + troubleshooting  ->   Boot diagnostics

Boot Diagnostics

https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-grub-single-user-mode

https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/boot-diagnostics

https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-contributor

GrubLoader Issue

https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/troubleshoot-vm-boot-error

https://gutsytechster.wordpress.com/2018/07/24/how-to-resolve-grub-error-file-grub-i386-pc-normal-mod-not-found/

https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-grub-proactive-configuration

https://www.youtube.com/watch?v=KevOc3d_SG4

https://askubuntu.com/questions/266429/error-file-grub-i386-pc-normal-mod-not-found

10.79.202.5

fda

Rage@1234567

azureubuntu

azlinux

R....1......e2021

GRand Unified Bootloader (GRUB) is likely the first thing you see when you boot a virtual machine (VM). Because it's displayed before the operating system has started, GRUB isn't accessible via SSH. In GRUB, you can modify your boot configuration to boot into single-user mode, among other things.

REISUB

az vm start -g CORA-AI -n FDA-VEA

az vm restart -g CORA-AI -n FDA-VEA

az vm restart -g CORA-AI -n FDA-VEA --force  --no-wait

az serial-console send reset -g CORA-AI -n FDA-VEA

az serial-console send reset -g CORA-AI -n FDA-VEA

az vm boot-diagnostics get-boot-log -g CORA-AI -n FDA-VEA

az serial-console connect -g CORA-AI -n FDA-VEA

az serial-console send reset -g CORA-AI -n FDA-VEA

az vm boot-diagnostics enable -g CORA-AI -n FDA-VEA

$subscriptionId=$(az account show --output=json | jq -r .id)

az resource show --ids "/subscriptions/$subscriptionId/providers/Microsoft.SerialConsole/consoleServices/default" --output=json --api-version="2018-05-01" | jq .properties

Multisite - Listener - Azure Application Gateway

https://docs.microsoft.com/en-us/azure/application-gateway/multiple-site-overview#wildcard-host-names-in-listener-preview

https://docs.microsoft.com/en-us/azure/application-gateway/configuration-overview#listeners

Azure : Devops : Pipelines: Task ::: Cache Task

https://docs.microsoft.com/en-us/azure/devops/pipelines/release/caching?view=azure-devops

https://docs.microsoft.com/en-us/azure/devops/pipelines/release/caching?view=azure-devops#maven

Maven

Maven has a local repository where it stores downloads and built artifacts. To enable, set the maven.repo.local option to a path under $(Pipeline.Workspace) and cache this folder.

Example:

YAML

variables:
  MAVEN_CACHE_FOLDER: $(Pipeline.Workspace)/.m2/repository
  MAVEN_OPTS: '-Dmaven.repo.local=$(MAVEN_CACHE_FOLDER)'

steps:
- task: Cache@2
  inputs:
    key: 'maven | "$(Agent.OS)" | **/pom.xml'
    restoreKeys: |
      maven | "$(Agent.OS)"
      maven
    path: $(MAVEN_CACHE_FOLDER)
  displayName: Cache Maven local repo

- script: mvn install -B -e

If you are using a Maven task, make sure to also pass the MAVEN_OPTS variable because it gets overwritten otherwise:

Azure:Devops Stakeholder:Basic Access

https://stackoverflow.com/questions/48863308/in-vsts-how-to-move-access-level-from-stakeholder-to-basic-access

https://docs.microsoft.com/en-us/azure/devops/organizations/security/access-levels?view=azure-devops

Supported access levels

Assign users or groups of users to one of the following access levels:

• Stakeholder: Provides partial access, can be assigned to unlimited users for free. Assign to users with no license or subscriptions who need access to a limited set of features.
• Basic: Provides access to most features. Assign to users with a Visual Studio Professional subscription, an Azure DevOps Server CAL, and to users for whom you're paying for Basic access in an organization.
• Basic + Test Plans: Provides access to all features included in Basic, as well as Azure Test Plans. Assign to users with a Visual Studio Test Professional or MSDN Platforms subscription, and to users for whom you're paying for Basic + Test Plans access in an organization.
• Visual Studio subscription: Assign to users who already have a Visual Studio subscription. The system automatically recognizes the user's subscription—Visual Studio Enterprise, Visual Studio Professional, Visual Studio Test Professional, or MSDN Platform—and enables any other features that are included in their subscription level. If you assign Basic or Stakeholder, they also receive their Visual Studio subscription benefits upon sign-in.

Azure Agent - Configure As a Service Linux or Standalone or Nohup &

https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops

#Configure it as a linux process and using nohup &

./run.sh 

ps -ef --sort=start_time |grep -E 'Agent|run.sh'

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

#Configure Listener as a service in Linux, It actually, starts 3 Services 

sudo ./svc.sh install    #Creates a symlink under /etc/systemctl/system

sudo ./svc.sh start

sudo ./svc.sh status

sudo ./svc.sh uninstall  #Uninstall Service(SystemD) ,You should stop before you uninstall.

ps -ef --sort=start_time |grep -E 'Agent|runsvc'

ps -ef --sort=start_time |grep -E 'vsts|Agent|run.sh'

sudo systemctl is-active 'vsts.agent.GenpactDigitalEngineering.eks\x2ddev.dev.service'

sudo systemctl is-enabled 'vsts.agent.GenpactDigitalEngineering.eks\x2ddev.dev.service'

sudo systemctl status 'vsts.agent.GenpactDigitalEngineering.eks\x2ddev.dev.service'

#Configure Listener as a service in Linux, It actually, starts 3 Services 

Loaded: loaded (/etc/systemd/system/vsts.agent.GenpactDigitalEngineering.eks\x2ddev.dev.service; enabled; vendor preset: enabled)

   Active: active (running) since Sat 2021-06-26 04:12:27 UTC; 17min ago

 Main PID: 27333 (runsvc.sh)

    Tasks: 21 (limit: 4915)

   CGroup: /system.slice/vsts.agent.GenpactDigitalEngineering.eks\x2ddev.dev.service

           ├─27333 /bin/bash /home/eks/agent/runsvc.sh

           ├─27336 ./externals/node/bin/node ./bin/AgentService.js

           └─27356 /home/eks/agent/bin/Agent.Listener run --startuptype service

Remove and re-configure an agent (Not Service) The Whole Agent

To remove the agent:

1) Stop and uninstall the service as explained above.

2) Remove the agent.            [As it appears in Agent Pool]

./config.sh remove  [Enter your credentials.]

After you've removed the agent, you can configure it again.

SSL can be embedded in DNS - DNS is Network level , Not Http Level

DNS is LEVEL4 - N/W Layer

HTTPS/SSL is Layer 7(6)  - Above 4

So, DNS is merely Server resolving , it does not know anything at SSL TLS HTTPS level

So, We direct DNS to Load Balancer 

Load Balancer has a listener which redirects traffic internally 

Load Balancer is at TCP Port 80

TCP Port 80 redirects to Port 443 at Load balancer Level

here at LB SSL offloading Happens

PFX File, CER File is issued to "DNS Name " and "Subject Alternative Names" to FQDN of Host Backends

DNS has Record Set Types:

A record

CNAME record

NS record

Install Powershell for AZURE - Azure CLI

How to install Powershell for Azure

https://www.parallels.com/blogs/ras/azure-powershell/

Set-ExecutionPolicy RemoteSigned

Install-Module -Name Az -AllowClobber

Connect-AzAccount -DeviceCode                        [Enter Device Code on Browser after opening it]

Azure Pipelines, YAML Schema

https://docs.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops&tabs=schema%2Cparameter-schema

https://docs.microsoft.com/en-us/azure/devops/pipelines/get-started/key-pipelines-concepts?view=azure-devops

https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml#ci-triggers

https://faun.pub/reduce-your-build-time-using-caching-in-azure-pipelines-7a7bd0201cee

Resources

Trigger

Pipeline -> Stage(Implicit) -> Jobs -> Steps [Task, Script, Checkout]

jobs:

- job: Job_1

  displayName: Agent job 1   

  pool:

    vmImage: ubuntu-latest

  steps:

    -script: echo "Hello World"

pool:

  name: Default

  demands: SpecialSoftware # Check if SpecialSoftware capability exists

  

  

stages:

- stage: A

  jobs:

  - job: A1

  - job: A2

- stage: B

  jobs:

  - job: B1

  - job: B2  

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml

stages:

- stage: A

# stage B runs if A fails

- stage: B

  condition: failed()

# stage C runs if B succeeds

- stage: C

  dependsOn:

  - A

  - B

  condition: succeeded('B')

If you choose to specify a pool at the stage level, then all jobs defined in that stage will use that pool unless otherwise specified at the job-level.

stages:

- stage: A

  pool: StageAPool

  jobs:

  - job: A1 # will run on "StageAPool" pool based on the pool defined on the stage

  - job: A2 # will run on "JobPool" pool

    pool: JobPool

jobs:

- job: Foo

  steps:

  - script: echo Hello!

    condition: always() # this step will always run, even if the pipeline is canceled

- job: Bar

  dependsOn: Foo

  condition: failed() # this job will only run if Foo fails

https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml

jobs:

- job: Debug

  steps:

  - script: echo hello from the Debug build

- job: Release

  dependsOn: Debug

  steps:

  - script: echo hello from the Release build

You can organize pipeline jobs into stages. Stages are the major divisions in a pipeline: "build this app", "run these tests", and "deploy to pre-production" are good examples of stages. They are logical boundaries in your pipeline where you can pause the pipeline and perform various checks.

Pipeline > Stages >Stage>Steps>Step

jobs:

- job: A

  steps:

  - bash: echo "A"

- job: B

  steps:

  - bash: echo "B"

  

  

  If you organize your pipeline into multiple stages, you use the stages keyword.

If you choose to specify a pool at the stage level, then all jobs defined in that stage will use that pool unless otherwise specified at the job-level

stages:

- stage: A

  jobs:

  - job: A1

  - job: A2

- stage: B

  jobs:

  - job: B1

  - job: B2

  

  When you define multiple stages in a pipeline, by default, they run sequentially in the order in which you define them in the YAML file. The exception to this is when you add dependencies. With dependencies, stages run in the order of the dependsOn requirements

  stages:

- stage: string

  dependsOn: string

  condition: string

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

  You can organize your pipeline into jobs. Every pipeline has at least one job. A job is a series of steps that run sequentially as a unit. In other words, a job is the smallest unit of work that can be scheduled to run.

  

  In the simplest case, a pipeline has a single job. In that case, you do not have to explicitly use the job keyword

  

  jobs:

- job: myJob

  timeoutInMinutes: 10

  pool:

    vmImage: 'ubuntu-16.04'

  steps:

  - bash: echo "Hello world"

  

  

  /usr/lib/jvm/adoptopenjdk-11-hotspot-amd64

 # update-alternatives --config java

          update-alternatives --list java

          echo ls /etc/alternatives

          ls /etc/alternatives

  

  

https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml

https://faun.pub/reduce-your-build-time-using-caching-in-azure-pipelines-7a7bd0201cee

Azure Devops, Azure, YAML, Conditional Tasks

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/conditions?view=azure-devops&tabs=yaml

When we specify Condition, we actually make the execution of step conditional to the outcome of execution of previous step.

You can specify conditions under which a step, job, or stage will run.

• Only when all previous dependencies have succeeded. This is the default if there is not a condition set in the YAML.

• Even if a previous dependency has failed, unless the run was canceled. Use succeededOrFailed() in the YAML for this condition.

• Even if a previous dependency has failed, even if the run was canceled. Use always() in the YAML for this condition.

• Only when a previous dependency has failed. Use failed() in the YAML for this condition.

• Custom conditions

1 2 3 4 5 6 7 8 9 10

jobs: - job: Foo steps: - script: echo Hello! condition: always() # this step will always run, even if the pipeline is canceled - job: Bar dependsOn: Foo condition: failed() # this job will only run if Foo fails