After Meteor cluster simple setup, I am presently getting this on the log
I20180719-11:04:44.210(1)? Cluster: connecting to 'mongodb' discovery backend
I20180719-11:04:44.297(1)? Cluster: with options: undefined
I am of the opinion that more configuration is needed than what I have done here Using Meteor Cluster for microservice but I seem not to find any documentation pointing to it.
How can I get the full setup?
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.
I have set up kong in dbless mode on RHEL by following the below documentation
https://docs.konghq.com/gateway/latest/install-and-run/rhel/
Kong gateway is successfully started. Below are the configurations I added in kong.conf file where database is turned to off and path to declarative kong.yaml is specified
declarative_config = /temp/kong/kong.yml
database = off
Also, below is current .yaml file where I created a service using below link
https://docs.konghq.com/gateway/2.8.x/get-started/comprehensive/expose-services/
_format_version: "1.1"
services:
- host: mockbin.org
name: example_service
port: 80
protocol: http
routes:
- name: mocking
paths:
- /mock
strip_path: true
I have also installed deck to sync this the declarative configuration.
However, when I use the deck sync command to add this service to kong, I get below error
creating service example_service
Summary:
Created: 0
Updated: 0
Deleted: 0
Error: 1 errors occurred:
while processing event: {Create} service example_service failed: HTTP status 405 (message: "cannot create or update 'services' entities when not using a database")
Kindly need ideas on what could be wrong as I believe we can create a service in dbless mode, and I also think that this is the declarative format which should work. Looking forward to hear. Thanks
Kindly need ideas on what could be wrong as I believe we can create a service in dbless mode, and I also think that this is the declarative format which should work. Looking forward to hear. Thanks
You are correct that we can create a service in dbless mode, however the approach will be different.
If you already have the new config file in yaml format. you can load it to Kong using /config endpoint
I also think that decK should be process-agnostic and can be used with both db and dbless mode, But as it stands, loading yaml config file with /config endpoint looks like the best option.
I am trying to craft a salt state file to simply ensure-enabled and re-run my one-shot service. I thought it would be nice to re-run if any of the dependent files changed, but honestly this is simple enough and the short-lived service is almost never going to be running when I want to update.
Current attempt:
myown-systemd-service-unit-file:
...
myown-systemd-service-executable-file:
...
myown-service:
systemd.force_reload:
- name: myown
- enable: True
- watch:
- myown-systemd-service-unit-file
- myown-systemd-service-executable-file
is failing at with errror:
----------
ID: myown-service
Function: systemd.force_reload
Name: myown
Result: False
Comment: State 'systemd.force_reload' was not found in SLS 'something.myown'
Reason: 'systemd.force_reload' is not available.
Changes:
By enable, I mean to have the equivalent of this CLI call be applied:
sudo systemctl enable myown.service
Relevant docs: https://docs.saltproject.io/en/latest/ref/modules/all/salt.modules.systemd_service.html#module-salt.modules.systemd_service
The systemd_service module is an execution module, and the syntax to use such modules is slightly different. The state declaration you are using is for state modules. Also, the example from the documentation points to use of service.force_reload rather than systemd.force_reload.
salt '*' service.force_reload <service name>
Considering all this, the below example restarts and enables myown service when the service unit file changes.
myown-service:
module.run:
- service.restart:
- name: myown
onchanges:
- file: myown-systemd-service-unit-file
- service.enable:
- name: myown
Note that I've used restart instead of force_reload to bounce the service. Also I'm using onchanges for file module as you haven't shown how you manage the two files. You can use the appropriate module and state IDs.
I'm attempting to run Spring Cloud Configuration Server, working through the examples in a book (Manning's Spring Microservices in Action), but updating to the latest versions: Java 17, spring-boot-starter-parent 2.6.1, with Spring Cloud 2021.0.0-RC1.
Each time I try to start the server, I get this error:
***************************
APPLICATION FAILED TO START
***************************
Description:
Invalid config server configuration.
Action:
If you are using the git profile, you need to set a Git URI in your configuration. If you have set spring.cloud.config.server.bootstrap=true, you need to use a composite configuration.
I am not using the git profile. I have tried two different profiles: native (with config files on the classpath) and vault (with a Hashicorp Vault server running locally). My latest /src/resources/bootstrap.yml contains the following:
spring:
application:
name: config-server
profiles:
active: vault
cloud:
config:
server:
vault:
port: 8200
host: 127.0.0.1
kvVersion: 2
server:
port: 8071
My best guess is that the bootstrap.yml file isn't getting picked up at server startup, and perhaps the git profile is a default. How can I remedy this?
OK, it looks like the problem here is that newer versions of Spring Cloud Configuration Server don't look for the bootstrap.yml file by default. There are a few different ways to solve it. The easiest is just to move all the properties to an application.yml/application.properties instead.
Another alternative is (found at NEWBEDEV here) is to include a dependency that implements the "legacy" bootstrap behavior:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>
add the following into application.properties file.
spring.application.name=techefx-spring-cloud-config-server
spring.cloud.config.server.git.uri=https://github.com/techefx/environment-variable-repo.git
server.port= ${port:8888}
Please go through the link below:
Spring Cloud Config File System Backend Issue (not reading properties from the file)
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.