It is too easy to run playbooks on the wrong hosts in Ansible

I know the best practice would be to use --limit to make sure you can not select the wrong host. I do not trust --limit to ensure Ansible runs playbooks only on the intended hosts.

Is it a crazy idea to use firewalld to disable communication to all the systems you do not want to update? Is there a more logical way to accomplish the same thing?

This could be done with a dynamic block but its pretty complicated. This is how I would do it but there are other ways.

variable "enable_vars" {
  type        = bool
  default     = false
}
locals {

default_lambda_vars = {

FOO = 1

}

extra_vars = {

BAR = 2

BAZ = 3

}
final_lambda_vars = var.enable_vars ? merge(local.default_lambda_vars, local.extra_vars) : local.default_lambda_vars

}
resource "aws_lambda_function" "mylambda" {
#...

environment {
    variables = local.final_lambda_vars
}

}

I am developing a https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/registry-private.html for AWS https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/registry.html . I have designed my model schema and developed my handler code, https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/resource-type-walkthrough.html#resource-type-walkthrough-submit it, and even successfully deployed a stack with my very own private resource type. Yay.

What i need to do now is inspect the logging thereof. As I had generated the scaffolding using the cfn init command, i merely added logging entries to the existing logger object.

e.g.

# Use this logger to forward log messages to CloudWatch Logs.
LOG = logging.getLogger(__name__)
TYPE_NAME = "Myself::Test::Resourceful"
resource = Resource(TYPE_NAME, ResourceModel)

test_entrypoint = resource.test_entrypoint
@resource.handler(Action.CREATE)

def create_handler(

session: Optional[SessionProxy],

request: ResourceHandlerRequest,

callback_context: MutableMapping[str, Any],

) -> ProgressEvent:

model = request.desiredResourceState

progress: ProgressEvent = ProgressEvent(

status=OperationStatus.IN_PROGRESS,

resourceModel=model,

)

# TODO: put code here
LOG.info('Creating....')

According to the https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/resource-type-develop.html#resource-type-develop-log ,

When you register a resource type using cfn submit, CloudFormation creates a CloudWatch log group for the resource type in your account. This enables you to access the logs for your resource to help you diagnose any faults. The log group is named according to the following pattern:

/my-resource-type-stack-ResourceHandler-string

Now, when you initiate stack operations for stacks that contain the resource type, CloudFormation delivers log events emitted by the resource type to this log group.

When submitting my resource type however (and even deploying it), a cannot see any LogGroup created in CloudWatch whatsoever. There is clearly something i am missing here.

Please help me understand how to find the logging for my private Cloudformation registry resource types.

Of course, i will be happy to provide any additional info needed. Thank you!

I have enabled Azure Monitoring in one of our virtual machine. Is been 4 days the virtual machine is on, below is the query:

Perf
| where ObjectName == "Memory" and
(CounterName == "Available MBytes Memory" or // the name used in Linux records
CounterName == "Available MBytes") // the name used in Windows records
|  summarize avg(CounterValue) by bin(TimeGenerated, 15min), Computer, _ResourceId // bin is used to set the time grain to 15 minutes
| render timechart

The output of Perf itself is empty. The same thing goes for Update, it show me zero results.

These are the two extensions I have installed on the VM

Also I have created the Data collection rule to send below data to the log analytics

Any suggestions?

One simple way would be to delegate the subdomain of mydomain.com for each account to that account's Route53 service. After you do this, the credentials that allow Terraform to create load balancers, servers, and other things in the Dev account can also create/update/delete the DNS records for dev.mydomain.com. The different credentials that manage resources in the Stage account can also manage DNS entries in stage.mydomain.com. The DNS for the different accounts is kept separate just like the other resources.

The way to do this is to create dev.mydomain.com as a public domain in the Dev account's Route53. Take down the list of DNS servers reported there, and add them as NS records for the name dev.mydomain.com in the Root account's Route53. Follow a similar pattern for the subdomains for the other accounts.

What does TCP 10256 do and where is to documented. According to the https://rancher.com/docs/rancher/v2.5/en/installation/requirements/ports/#rancher-aws-ec2-security-group it's open. But I don't see any documentation on port 10256 elsewhere.

It's also documented on the similar https://rancher.com/docs/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/azure/azure-machine-config/

main.tf

  module "s3_bucket" {
  source = "./modules/S3"
  kms_master_key_id = module.kms.kms_arn
}
module "kms" {

source = "./modules/kms"

}

modules/kms/kms.tf

resource "aws_kms_key" "key" {
  policy = data.aws_iam_policy_document.cmk.json
}
resource "aws_kms_alias" "key_alias" {

name          = "alias/kms-key"

target_key_id = aws_kms_key.key.id

}

modules/kms/_outputs.tf

output "kms_arn" {
  value = aws_kms_key.key.arn
}

modules/S3/main.tf

resource "aws_s3_bucket" "bucket" {
bucket = "09432804238423098"

acl    = "private"

versioning {

enabled = false

}

force_destroy = true

server_side_encryption_configuration {

rule {

apply_server_side_encryption_by_default {

kms_master_key_id = var.kms_master_key_id

sse_algorithm     = "aws:kms"

}

}

}

}

modules/S3/variables.tf

variable "kms_master_key_id" {
  default = ""
}

Let's say I want to install an arbitrary helm chart like mysql-operator/mysql-innodbcluster how can I find what options I set with --set?

We have a manifest file that defines a set number of replicas and an autoscaler that scales them up. The problem we have is when we apply the manifest, it immediately scales the replicas down to the number in the manifest. This eventually is fixed by the autoscaler, but in the meantime, it's not great!

Is there a way to run a manifest and ignore the replica parameter?

We tried removing it, but then it scaled to the default count of 1.

From what I see in your terraform plan, terraform apply will indeed set the latest task definition version and probably run redeploy of your ECS.

You can keep your state file up-to-date with terraform plan --refresh-only to see the possible changes in infrastructure done manually, and if you are ok with it, terraform apply --refresh-only will save those changes in your terraform state file.

https://learn.hashicorp.com/tutorials/terraform/refresh is some more info on that subject.

Hope it helps