Apparently during the AMI creation process, the default user password gets locked - a ! is appended to the password in /etc/shadow.
I was able to just add passwd -u ubuntu to the user data of the launch template to unlock it and we are good to go.
I can't comment, so using an answer.
What exactly do you mean by "However, when they were finished there were no parallel jobs available in our account." If you use the MS hosted agents, and if you bought three parallel jobs, you should see them in the Organization settings -> Parallel jobs overview. If not, try lo log out, clear cache etc. The purchases are indeed for a month, as explained https://azure.microsoft.com/en-gb/pricing/details/devops/azure-devops-services/ , the costs would be about 40 euros for a month, so for three it would be around 120 euro a month.
As an alternative, and as suggested by others, you could use self hosted agents. They are cheaper, and depending on resources on the host where you install the agent, they run faster.
And then, depending on your needs, there are several ways that might speed up your deployment process, but that usually depends on what you've already configured and your needs.
And then last, if you are a really early user of DevOps, there was an option to pay for hosted agents by the minute. That could explain your situation, but I've checked several organizations inclusing a few already several years old but I can't find any reference of it.
I'm trying to create a set of subnet rules for a cosmosdb account.
I've tried a dynamic and a for_each on the resource and I get the same error each time - am I going about this the wrong way?
Currently trying this:
resource "azurerm_cosmosdb_account" "db" {
name = local.name
location = var.location
resource_group_name = var.resource_group_name
offer_type = "Standard" #(Required) Specifies the Offer Type to use for this CosmosDB Account - currently this can only be set to Standard.
enable_free_tier = var.enable_free_tier
kind = var.kind
identity {
type = "SystemAssigned"
}
ip_range_filter = join(",", local.network_rules.ip_rules)
dynamic "virtual_network_rule" {
for_each = var.virtual_network_subnet_ids
content {
id = each.value
}
}
}
Currently getting:
Error: each.value cannot be used in this context
│
│ on .terraform/modules/azurerm_cosmosdb_account/azurerm_cosmosdb_account/main.tf line 27, in resource "azurerm_cosmosdb_account" "db":
│ 27: id = each.value
│
│ A reference to "each.value" has been used in a context in which it
│ unavailable, such as when the configuration no longer contains the value in
│ its "for_each" expression. Remove this reference to each.value in your
│ configuration to work around this error.
╵
Maybe a readiness probe will help. The api server will in this case call your pods on /health and a http status error code means not ready, else ready. As long as the service is not ready, calls will not be routed.
- name: name
image: "docker.io/app:1.0"
imagePullPolicy: Always
readinessProbe:
httpGet:
path: /health
port: 5000
initialDelaySeconds: 5
And in your code
@app.route("/health")
def health():
if not os.path.exists('gitfile'):
return "not ok", 500
return "OK", 200
or else a livenessprobe with checks the return value of the utilities called. zero means success, else fail.
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
I'm trying to get a feel for the Kubernetes Nginx ingress controller. Trying to deploy it to an AKS cluster, however I can't figure out the following. According to https://docs.microsoft.com/en-us/azure/aks/ingress-basic?tabs=azure-cli
To control image versions, you'll want to import them into your own Azure Container Registry. The NGINX ingress controller Helm chart relies on three container images. Use az acr import to import those images into your ACR.
So, I've pulled, tagged and pushed the controller, patch and default backend images to ACR.
Next, did helm show values ingress/nginx/ingress-nginx > values.yaml and created a new .yaml to reference it a installation time (so that it can grab the images from ACR rather than the default repo).
However, after install I'm surprised to find only 1 pod related to nginx
NAME READY STATUS RESTARTS AGE
ingress-nginx-controller-764784f688-qbbq8 1/1 Running 0 49m
I've even tried to install it with the defaults without providing my own .yaml with -f foo.yaml like this:
helm upgrade --install ingress-nginx ingress-nginx --repo https://kubernetes.github.io/ingress-nginx --namespace ingress-nginx --create-namespace
But still only 1 pod:
NAME READY STATUS RESTARTS AGE
ingress-nginx-controller-6bf7bc7f94-ml4js 1/1 Running 0 55s
Per my understanding this is what gets created:
What am I missing please ?
I'm struggling to understand the difference between the following Terraform Resources:
Example 1:
resource "aws_route_table" "public_1" {
vpc_id = aws_vpc.test.id
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.main.id
}
tags = {
Name = "test-route"
}
}
resource "aws_route_table_association" "test_pub_route" {
subnet_id = aws_subnet.test_pub.id
route_table_id = aws_route_table.public_1.id
}
Correct me if I'm wrong but in this example I'm just creating a route and a route table with public_1 resource.
In the second part I'm just associating the public_1 route table subnet called test_pub.
Question 1:
I don't understand what does the block route do in public_1
The documentation https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/route_table doesn't make much sense to me.
Example 2:
resource "aws_route_table" "public" {
vpc_id = aws_vpc.main.id
}
resource "aws_route" "public" {
route_table_id = aws_route_table.public.id
destination_cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.main.id
}
resource "aws_route_table_association" "public" {
subnet_id = aws_subnet.test_pub.id
route_table_id = aws_route_table.public.id
}
Question 2(main)
I'm trying to understand if these two examples are actually the same. And that the only difference is that in the first example we have route block which is equivalent to resource aws_route in the second example.
Even the required variables are the same just name is little bit different.
Is it possible to print to helm install (or helm upgrade) output the logs of the deploying containers (logs that are available by kubectl logs command)?
When I define the daily capacity of a developer during a sprint and this value contains a dot (e.g. 2.5 hours), after I save the changes the developer will have a daily capacity of 25 hours.
Daily capacity of the developer before saving the changes:
Daily capacity of the developer after saving the changes:
When I use a comma instead of the dot, this problem won't occur.
Is there any way to change this behavior in Azure DevOps, so that the dot can be used instead of the comma?
I found the solution by doing the following:
Inside db.myserver.com server create a new ssh tunnel:
ssh -L UNIQUE_LOCAL_PORT:REMOTE_HOST:REMOTE_PORT authorized_ssh_user@remotehost -N
Authentication is passwordless because I already added ssh_user key to ~/.ssh/authorized_keys on remotehost
Suppose I assigned port 10001 to b.myserver.com, I can connect to it trought: i.e.
ssh -L 10001:127.0.0.1:3306 authorized_ssh@b.myserver.com -N
The tricky part to understand is that I have to use 127.0.0.1 as REMOTE_HOST instead of its public ip. That's because destination is reached over an ssh tunnel, so the connection is like it starts locally. So 127.0.0.1 is the ip of the database as seen from inside b.myserver.com
to connect from db.myserver.com to b.myserver.com I just specify port 10001. If I want to connect to c.myserver.com I just have to set up another tunnel and to specify another port.
mysql -u user_b -p -h 127.0.0.1 -p 10001
Hope it helps 
I found https://stackoverflow.com/questions/39940552/no-plugin-goals-bound-to-a-maven-phase answered on Stack Overflow and, according to it, ...