Troubleshooting puppet and hiera

14-Mar, 2016

I am currently working on a project that has a reasonable amount of complex data in stored in hiera. For security we are using eyaml with AWS KMS encryption to secure the data.

The data is hierarchical and moves from the generic to the specific and is merged together within puppet by using hiera hashes. The problem is that when this configuration is mis-configured (i.e. missing or invalid key) the output from hiera/puppet is not particularly helpful.

If you add the –trace command to your puppet command such as this:

puppet apply my_manifest.pp --verbose --debug --trace

This will give you the stack trace of the command where it failed. You can then add the appropriate ruby “puts” statements to increase the debugging and this should hopefully allow you to more accurately diagnose the issue.

Comments

Application Transformation and the Tail

19-Oct, 2015

For many large enterprises the problem with application transformation (or application migration) is the “long tail”. In my experience there are three different types of applications:

  • Upstarts - These are applications that are newly built. These applications adhere to the latest corporate/industry standards and often use the latest technology. The development teams for this are largely still in place and the architectural team supports the design decisions. This project is the current golden project that people are proud to be associated with. Today’s upstarts will become tomorrows Class Pets or Ugly Ducklings.
  • Class pets - These projects are a little bit older and often represent a mission critical function that requires relatively frequent change. There is an active development team supporting the application and good management support for changes. While the codebase may not be cutting edge, the application is well understood and an application transformation is largely a known entity.
  • Ugly Ducklings - These application may be important (even mission critical) but development has largely been completed. Other than tinkering at the edges (textual changes to HTML pages etc) these applications are generally unchanged. The development teams have moved on, and those developers that are still with the organization don’t want to touch this one again. The application is probably running on out of support infrastructure and software and these applications are flagged on auditors reports for modernization.

Generally it is the “Ugly Ducklings” that take the vast majority of effort to migrate, almost adhering to the 80-20 rule from the Pareto Principle, but when we (collectively as an industry) estimate migration we tend to only focus on the “Upstarts” and “Class Pets” because they consume the bulk of our day to day effort and they are the best understood.

Some calculations estimate the migration effort of the “Class Pets” and then extrapolate that figure across the “Ugly Ducklings”, little realizing that the “Ugly Ducklings” are inherently more risky than a “Class Pet”. This approach leads to an initial rush of migrated applications (as the Upstarts and Class Pets get moved across to the new infrastructure) but momentum quickly disappears when the effort moves to the “Ugly Ducklings”. In a worst case scenario the migration effort ceases all together (sometimes because funds are exhausted before work is completed) and we are left with an organization with a partially migrated application stack. The promises of the massive consolidation (and associated savings) that initially underpinned the project are instead missed and the organization is instead burdened with increased costs from supporting both the old and new world.

Much of the talk of moving applications to the cloud generally focuses on “Upstarts”, where an organization builds a new application in the stack. In a way, this is pretty easy (although aligning legacy operational and security procedures to the cloud can be very challenging) because you can build the application “cloud first” - using cloud technologies. The difficulty comes in migrating your existing “Ugly Ducklings” onto the cloud.

In future posts, I shall describe in more detail how to approach migrating these ugly ducklings to the cloud.

Comments

Creating an IAM Policy for S3 Web Access

19-Apr, 2015

It is well documented how to create an S3 bucket that can be used to host a static site but I didn’t find the process of creating an IAM policy for securing the bucket that clear. Here is my IAM policy for an S3 bucket that we are using to host a static website:

{
    "Version": "2012-10-17",
    "Statement": [
    {
      "Action": [
        "s3:ListAllMyBuckets"
        ],
        "Effect": "Allow",
        "Resource": "arn:aws:s3:::*"
    },
    {
      "Action": [
        "s3:ListBucket",
        "s3:DeleteObject",
        "s3:GetBucketAcl",
        "s3:GetBucketLocation",
        "s3:GetObjectAcl",
        "s3:PutBucketAcl",
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::domain.com",
        "arn:aws:s3:::domain.com/*",
        "arn:aws:s3:::www.domain.com",
        "arn:aws:s3:::www.domain.com/*"
      ]
    }
  ]
}

If anyone has any better policies for securing a bucket we would love to hear them!

Comments

More Posts..