I'm using Cloudify (version 3.2.1) together with the AWS plugin, and want to set the name my instance in the Amazon cloud. But to upload the blueprint below:
...
node_templates:
mysql_host:
type: cloudify.aws.nodes.Instance
properties:
image_id: { get_input: image }
instance_type: { get_input: size }
name: my_ec2_instance
The error occurs:
Failed to validate blueprint wordpress-blueprint.yaml: mysql_host node 'name' property is not part of the derived type properties schem
If I retreat and line: name: my_ec2_instance, the upload occurs without errors.
How can I set the name of my instance on AWS?
the name property is only available in Cloudify AWS Plugin v > 1.3.1, which is only supported in Cloudify 3.3.1.
In AWS Plugin 1.3.1 you could set the name by setting it explicitly in the key_name key under the parameters property.
Please see [http://docs.getcloudify.org/3.3.1/plugins/aws/#cloudify-aws-nodes-instance] for more information.
Related
The Jelastic Marketplace is full of interesting software. However, sometimes, they do not comply to my security needs. In those cases, I would like to write my own manifest that would install the manifest from the marketplace and add up the components that I need for my use-case. Let's take an example: I would like to wrap the kubernetes installation with the addition of a load-balancer. I would like to do something like this:
type: install
name: My Example Manifest
onInstall:
- install:
jps: https://github.com/jelastic-jps/kubernetes/blob/1.23.6/manifest.jps
envName: env-${fn.random}
settings:
deploy: cmd
cmd: echo "do nothing"
topo: 0-dev
dashboard: general
ingress-controller: Nginx
storage: true
api: true
monitoring: true
version: 1.23.6
jaeger: false
- addNodes:
- nodeType: nginx-dockerized
nodeGroup: bl
count: 1
fixedCloudlets: 1
flexibleCloudlets: 4
The issue I am having here is that the manifest cannot add the nodes, because of the following error:
user [xyz] doesn't have any access rights to app [dashboard]
What am I doing wrong? How can I make this manifest work? I tried to set user: root in the addNodes function but it doesn't help.
Of course, I am interested in suggestions involving one single install manifest. I know I could make it happen by first installing the kubernetes manifest and then running an update manifest that would add my load-balancer nodes. I would like, however, to package the whole thing within one single step, as described by my manifest above.
How can i create a nginx ingress in azure kubernetes using terraform, earlier in this link , i remember seeing some steps as a mandatory installation for all setups, right now it seems to be removed and there is a specific way of installing for aks in this link, should i rewrite all these to adapt to terraform or is there any other smart way of installing nginx ingress for aks through terraform
You could try using Terraform's helm provider.
provider "helm" {
kubernetes {
host = azurerm_kubernetes_cluster.your_cluster.kube_config.0.host
client_key = base64decode(azurerm_kubernetes_cluster.your_cluster.kube_config.0.client_key)
client_certificate = base64decode(azurerm_kubernetes_cluster.your_cluster.kube_config.0.client_certificate)
cluster_ca_certificate = base64decode(azurerm_kubernetes_cluster.your_cluster.kube_config.0.cluster_ca_certificate)
}
}
data "helm_repository" "stable" {
name = "stable"
url = "https://kubernetes-charts.storage.googleapis.com"
}
resource "helm_release" "nginix_ingress" {
name = "nginx_ingress"
repository = data.helm_repository.stable.metadata.0.name
chart = "stable/nginx-ingress"
namespace = "kube-system"
}
If your cluster is already created, you will have to import it as well using a data source. helm_release also supports custom values. Here is the link if you need more information.
There is a nice tutorial Create an Application Gateway ingress controller in Azure Kubernetes Service. And you can check GitHub for Application Gateway Ingress Controller.
If you are using Terraform version 0.12 or higher you can use terraform provider kubernetes example.
As for the Terraform documentation you should check Data source kubernetes_ingress and Resource kubernetes_ingress.
If you provide more details I'll update the answer.
Updated answer
resource "helm_release" "nginix-ingress" {
name = "nginix-ingress"
repository = "https://charts.bitnami.com/bitnami"
chart = "nginx"
namespace = "kube-system"
}
I offer an alternative, in my opinion better, way to provision Kubernetes services like Nginx ingress using Terraform.
My kustomize based modules have two main benefits over using helm based modules:
Patching instead of templating makes maintaining custom configuration easier across new upstream versions
My kustomization provider, unlike the helm provider, shows detailed diffs and even destroy/recreate during terraform plan
If you're interested, here's a detailed comparison between my kustomize based Nginx ingress Terraform module and a helm based module.
Using the module is straight forward:
# require and configure provider
terraform {
required_providers {
kustomization = {
source = "kbst/kustomization"
}
}
}
provider "kustomization" {
alias = "example"
kubeconfig_path = "~/.kube/config"
}
# call module
module "example_nginx" {
providers = {
# we're using the alias provider we configured above
kustomization = kustomization.example
}
source = "kbst.xyz/catalog/nginx/kustomization"
version = "1.2.1-kbst.0" # find the latest version on https://www.kubestack.com/catalog/nginx
# the configuration here assumes you're using Terraform's default workspace
# use `terraform workspace list` to see the workspaces
configuration_base_key = "default"
configuration = {
default = {
replicas = [{
name = "ingress-nginx-controller"
count = 5
}]
}
}
}
The example module call uses kustomize's replicas attribute to change the replicas of the Nginx ingress controller.
The module's (I have them for more than just Nginx) allow defining the kustomization as part of the module call. They also bundle an upstream release, and you control the version using the version attribute.
Documentation for all available kustomization attributes can be found on the Kubestack website.
I maintain these modules as part of Kubestack, my open-source framework for platform teams working with Terraform and Kubernetes.
sudo juju bootstrap --constraints tags=juju mymaas maas-controller
Creating Juju controller "maas-controller" on mymaas
Looking for packaged Juju agent version 2.3.7 for amd64
Launching controller instance(s) on mymaas...
ERROR failed to bootstrap model: cannot start bootstrap instance: failed to acquire node: unexpected: ServerError: 400 BAD REQUEST ({"tags": ["No such tag(s): 'juju'."]})
Please refer to: https://docs.jujucharms.com/2.5/en/reference-constraints
This is an issue with tagging in MAAS as well as not using supported tags:
tags=juju mymaas maas-controller
This will specifically look for all servers with all of the tags:
juju
mymaas
maas-controller
Unless your maas controller has a server with all of those tags attached to it it will not find any servers and error out saying it cannot acquire a node with those tags, as it did.
Make the constraints match the supported standard, i.e. resource constraints.
Or, use a non-supported feature that I use when I deploy charms to maas and use the hostname.
juju bootstrap --to hostname.superdomain.com
this will search maas (assuming you have set it up correctly) for that hostname specifically and use it to bootstrap.
I am trying to use Artifactory as a front for our Helm Charts. I have the following set up:
helm-remote-stable : stable community Helm Charts
helm-local-stable : stable company Helm Charts
helm-stable: virtual repo with both of the above as upstreams
What's supposed to be happening is that the helm-stable virtual repo manages merging the two upstream index.yaml files.
However, I am getting the following exception in the logs:
2018-03-20 18:58:04,483 [art-exec-276943] [ERROR] (o.a.a.h.r.m.HelmVirtualMerger:194) - Couldn't read index file in remote repository helm-remote-stable : (was com.github.zafarkhaja.semver.UnexpectedCharacterException) (through reference chain: org.jfrog.repomd.helm.model.HelmIndexYamlMetadata["entries"]->java.util.LinkedHashMap["grafana"]->java.util.TreeSet[6])
It looks like Artifactory is trying to enforce semver through some library and it's not parsing the community index.yaml file. This breaks the entire feature of the product.
Here's what's breaking from the community index.yaml:
- created: 2018-01-28T21:04:13.090211594Z
description: The leading tool for querying and visualizing time series and metrics.
digest: 6c25c79e16df4c31637d3f8b1b379bb4c0a34157fa5b817f4c518ef50d43911b
engine: gotpl
home: https://grafana.net
icon: https://raw.githubusercontent.com/grafana/grafana/master/public/img/logo_transparent_400x.png
maintainers:
- email: zanhsieh#gmail.com
name: Ming Hsieh
name: grafana
sources:
- https://github.com/grafana/grafana
urls:
- https://kubernetes-charts.storage.googleapis.com/grafana-0.6.tgz
version: "0.6"
Please note the version: "0.6" which borking the entire thing.
Any idea on how to get around this? I am using the Artifactory cloud offering.
This was fixed in Artifactory version 5.9.0.
You can find more details here: https://www.jfrog.com/jira/browse/RTFACT-15668
have you tried changing the version of grafana chart from 0.6 to 0.6.0 and pushing it to helm-local-stable.
Can someone please provide me with a sample file for Packer creating OS image? I have this one:
{
"builders": [{
"type": "openstack",
"ssh_username": "ubuntu",
"tenant_name": "mytenant",
"flavor": "m1.tiny",
"identity_endpoint": "http://1.2.3.4:5000/",
"availability_zone": "az1",
"source_image": "Ubuntu 16.04 With Proxy",
"image_name": "Ubuntu 16.04 With Proxy and Python"
}],
"provisioners": [
{
"type": "shell",
"script": "python.sh"
}
]
}
but OS always returns:
==> openstack: Error launching source server: Invalid request due to incorrect syntax or missing required parameters.
I have no idea what I am missing.
Of course i have correct OS_ env values preset for my Nova API.
You have to use source_image_name or use the ID to reference the image
From the docs:
source_image (string) - The ID or full URL to the base image to use. This is the image that will be used to launch a new server and provision it. Unless you specify completely custom SSH settings, the source image must have cloud-init installed so that the keypair gets assigned properly.
source_image_name (string) - The name of the base image to use. This is an alternative way of providing source_image and only either of them can be specified.
See source_image