devopsy.kinsta.cloud

Tag: DevOps tool

  • Klocwork Is the Ideal Static Analysis Tool for DevOps

    Klocwork Is the Ideal Static Analysis Tool for DevOps

    Klocwork identifies software security, quality and reliability issues for C, C++, C# and Java helps to enforce compliance with standards. Its in-depth, accurate and precise analysis results have earned Klocwork the trust of industry leaders across a variety of industries. However, Klocwork is more than just a static code analysis tool; it’s also a static application security testing (SAST) tool.

    Find Security Vulnerabilities with SAST

    Klocwork SAST for DevOps and DevSecOps helps you to identify security vulnerabilities, which enables you to find and fix security issues earlier on in development. In addition, Klocwork helps you to ensure compliance with internationally recognized security standards.

    Differential Analysis

    Klocwork is one of the few static code analysis tools that uses differential analysis. This type of analysis enables Klocwork to provide you with shortest possible analysis times for the new and changed code—while maintaining the accuracy and detail of the analysis data.

    CI/CD Pipeline Support

    Built for enterprise DevOps, Klocwork scales to projects of any size, integrates with large complex environments and a wide range of developer tools, and provides control, collaboration and reporting. In addition, it integrates seamlessly with CI/CD pipelines to automate continuous compliance. This lowers cloud computing costs, as there are no idle instances waiting for the next analysis.

    Containerized Build Support

    Klocwork provides Containerized Build support for machine provisioning and cloud computing systems, including AWS, Azure and OpenStack. This provides the maximum flexibility and opportunity to use internal or external cloud services for code analysis.

    Control, Collaborate and Report

    The Klocwork Portal dashboard is a centralized store of analysis data, trends, metrics and configurations for codebases across the organization—accessed through a web browser. The dashboard is highly customizable, enabling your developers, managers and other stakeholders.

    Provide Your Team with Every Advantage — Provide Them with Klocwork

    To read more, please visit: https://www.perforce.com/sites/default/files/pdfs/datasheet-klocwork-static-analysis-tool-for-devops-web.pdf

  • The Right DevOps Tool for the Job

    The Right DevOps Tool for the Job

    Innovation and environment are only two factors in determining which DevOps tools are best for your organization

    Any time there is a movement in IT that involves a new space and new toolsets, there is sudden growth, then inevitably consolidation and, finally, a selection of tools that suit the needs of most customers. Then the cycle starts over. Usually by this point, users have developed a defense mechanism about their choices regarding which solutions to implement and discussions can get heated.

    I’m happy to say that the last bit—heated discussions—has not occurred with DevOps the way it has with other technologies (think the browser wars, OS dominance or even cloud service provider preferences). There is the occasional “You’re doing it wrong,” but not the wild-eyed flame-wars so far.

    But the other two? Yes, yes indeed. DevOps has been through a couple of cycles, and the end is nowhere in sight. I don’t necessarily see that as a bad thing; in fact, as long as innovation is occurring, you have the opportunity to look at changes and decide what can best help your DevOps efforts.

    My mantra since the language wars was that C, C++, VB, etc., were the “right tools for the job.” I have kept that mantra for all of IT. It is easy to adapt the tools you are familiar with—to do more than they were designed to—and most shops have fallen into this trap at some point. But a serious look at what is available and where the market seems to be evolving usually stops this kind of adaptation.

    Some shops use Jenkins for far more than it was designed for. It’s a great tool, but at some point, the benefits of using tools aimed at a given piece of the DevOps toolchain outweighs the fact that Jenkins could handle that bit.

    The popularity of Puppet is starting to cause the same issues, if anecdotal evidence is to be believed. In words I use to my children, “Just because you can, doesn’t mean you should.”

    The environment always plays a role in the “right tool for the job,” but it should not be the major factor. Having a DevOps tool that you already know that could do the job is one answer—but quite often not the best answer.

    So, use resources like us here at devopsy.kinsta.cloud, and your favorite site for IT ratings and reviews. Do some feature research, think about what it would take to make your existing tools do the same job, and consider bringing in new tools to achieve a given goal. We see so much change these days that sticking with what you know on this one tiny bit of the toolchain, may seem reasonable, but make sure you are not missing out on additional functionality or suitability to task over the long term.

    — Don Macvittie

  • DevOps Primer: Using Vagrant with AWS

    DevOps Primer: Using Vagrant with AWS

    One of the most common problems in modern software development is the phrase, “It works on my machine,” when a particular piece of code runs on developer’s machine but produces error on other team member’s machine. Thankfully, now there is a plugin that can help determine why something works only in particular environments, turning the phrase into more an observation than an excuse.

    Vagrant to the Rescue

    Vagrant is a tool for building and maintaining portable software development environments. It isolates your project’s dependencies and configuration from your projects without disturbing the tools your application is consuming. You could easily reproduce similar environments on other machines by using the same configuration as your machine.

    Basic Concepts in Vagrant

    Before going further, it is important to understand the following basic concepts that are essential to the working of Vagrant.

    Provisioners

    Provisioners provide automation for installing different software and configurations. It is useful in cases when you don’t want to install software manually to your machine.

    Providers

    Providers provide basic services that are required to run your machine. Although Vagrant provides support for VirtualBox, Hyper-V and Docker, other providers can also be used through appropriate plugin.

    Boxes

    Boxes are Vagrant environment packages that can be copied to any other machine to replicate a similar environment. Vagrant provides a repository of these boxes that can be downloaded, and you can contribute to the list by adding your own customized box.

    Install the Plugin

    The first step in the process is to make sure that you have Vagrant installed on your machine. As I mentioned earlier, you could use providers by installing the respective plugins. For the purpose of this tutorial, I will download the vagrant-aws plugin through the following command:

    vagrant plugin install vagrant-aws

    Next, verify the plugin installation through the command:

    vagrant plugin list

    The vagrant-aws plugin should be present in the plugins list

    Set Up the Vagrant Box

    After installing plugin, the next step is to install a Vagrant box. The problem is that there is no box for AWS provider. To make things work, I recommend you use the dummy box provided by Mitchell Hashimoto.

    Run the following command to add the dummy box:

    vagrant box add aws https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box

    Although I have named the box aws, you can give it any name that works for you. Once the process finishes, I am ready to create AWS instances.

    Create the Instance

    Run the vagrant init command to create a vagrant file:

    vagrant init

    Next, edit the vagrant file as follows:

    # -*- mode: ruby -*-
    # vi: set ft=ruby :

    # Require the AWS provider plugin
    require ‘vagrant-aws’

    # Creating and configuring the AWS instance
    Vagrant.configure(‘2’) do |config|

    # Use dummy AWS box
    config.vm.box = ‘aws’

    # Specify configuration of AWS provider
    config.vm.provider ‘aws’ do |aws, override|
    # Read AWS authentication information from environment variables
    aws.access_key_id = ‘ABCR2NDJKZJIAJ5QVXGJK’
    aws.secret_access_key = ‘WAuZE39lKHXAJnCfbZf2y6DzRfeCsPUU/yZMRDWo’

    # Specify SSH keypair to use
    aws.keypair_name = ‘vagrant’

    # Specify region, AMI ID, Instance and security group
    aws.region = ‘ap-southeast-2’
    aws.ami = ‘ami-14b55f76’
    aws.instance_type = ‘t2.micro’
    aws.security_groups = [‘default’]

    # Specify username and private key path
    override.ssh.username = ‘ubuntu’
    override.ssh.private_key_path = ‘~/vagrant/vagrant’
    end
    end

    Vagrantfile Explained

    The following list explains the important variables and aspects of the above file:

    • config.vm.box : Specify the box. Using dummy aws box for AWS deployment
    • aws.access_key_id : Access key ID of your Amazon account
    • aws.secret_access_key : The secret access key for your Amazon account
    • aws.keypair_name : Your SSH keypair in AWS
    • aws.region : The AWS region in which you want to create your instance
    • aws.ami : The AMI ID you want to use. AMI specifies the information needed to launch a virtual machine within EC2
    • aws.instance_type : The AWS instance you want to create
    • aws.security_groups : Specify the names of security groups that will be applied to your instance
    • override.ssh.username : The username that will be used to access the instance
    • override.ssh.private_key_path : The path of your SSH private key

    Launch the Instance

    After configuring the Vagrantfile, I will simply run the vagrant up command. Vagrant will launch an AWS instance through the AWS AMI provided in the configuration using the credentials provided in the Vagrantfile.


    You can view the newly created instance in the AWS console panel.

    You can now SSH into your AWS instance or perform other Vagrant operations.

    Final Words

    As you can see, using Vagrant to launch a AWS instance is simply a matter of installing the plugin and then launching the instances through easy steps. If you need help with the process, do leave a comment below.

    About the Author / Ali Azmi

    Ali Azmi is Associate DevOps Engineer at Cloudways – A Managed PHP Cloud Hosting Platform. He is skilled in developing PHP applications particularly in Laravel. He is passionate about contributing to open source projects.