opsgenie / oec Goto Github PK
View Code? Open in Web Editor NEWLicense: Apache License 2.0
License: Apache License 2.0
Is there any way to direct logging to stdout? oec seems to swallow up all the script output and send it to a file, but for a container it would be nice to not have to setup persistent storage just for logs. Stdout can be sent to another logger for collection, or just to debug.
Hi
generating a docker image from the Dockerfile in the repository root produces an artifact with multiple known CVEs which already have a fix.
please update
(.venv) ➜ code git clone https://github.com/opsgenie/oec.git
Cloning into 'oec'...
remote: Enumerating objects: 3320, done.
remote: Counting objects: 100% (17/17), done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 3320 (delta 2), reused 7 (delta 1), pack-reused 3303
Receiving objects: 100% (3320/3320), 13.83 MiB | 3.08 MiB/s, done.
Resolving deltas: 100% (1231/1231), done.
(.venv) ➜ code cd oec
(.venv) ➜ oec git:(master) ✗ docker build . -t oec
[+] Building 12.8s (17/17) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 813B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/python:alpine3.12 2.3s
=> [internal] load metadata for docker.io/library/golang:1.14 1.5s
=> [auth] library/python:pull token for registry-1.docker.io 0.0s
=> [auth] library/golang:pull token for registry-1.docker.io 0.0s
=> [internal] load build context 0.0s
=> => transferring context: 104.92kB 0.0s
=> CACHED [builder 1/4] FROM docker.io/library/golang:1.14@sha256:1a7173b5b9a3af3e29a5837e0b2027e1c438fd1b83bbee8f221355087ad416d6 0.0s
=> [base 1/5] FROM docker.io/library/python:alpine3.12@sha256:7f73901e568630443fc50e358b76603492e89c9bf330caf689e856a018f135f0 0.0s
=> [builder 2/4] ADD . /go/src/github.com/opsgenie/oec 0.1s
=> [builder 3/4] WORKDIR /go/src/github.com/opsgenie/oec/main 0.0s
=> [builder 4/4] RUN export GIT_COMMIT=$(git rev-list -1 HEAD) && CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -a -installsuffix cgo -ldflags "-X main.OECCommitVersion=$GIT_COMMIT -X main.OECVersion=1.0.1" -o nocgo -o /oec . 9.9s
=> CACHED [base 2/5] RUN pip install requests 0.0s
=> CACHED [base 3/5] RUN addgroup -S opsgenie && adduser -S opsgenie -G opsgenie && apk update && apk add --no-cache git ca-certificates && update-ca-certificates 0.0s
=> CACHED [base 4/5] COPY --from=builder /oec /opt/oec 0.0s
=> CACHED [base 5/5] RUN mkdir -p /var/log/opsgenie && chown -R opsgenie:opsgenie /var/log/opsgenie && chown -R opsgenie:opsgenie /opt/oec 0.0s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:1a131a4c33851d29490fdb82e6c2ac53268b3e240cfdc64407b7be1206d09a82 0.0s
=> => naming to docker.io/library/oec
(.venv) ➜ oec git:(master) ✗ grype --only-fixed oec:latest
✔ Vulnerability DB [no update available]
New version of grype is available: 0.52.0 (currently running: 0.51.0)
✔ Loaded image
✔ Parsed image
✔ Cataloged packages [77 packages]
✔ Scanned image [92 vulnerabilities]
[0002] WARN some package(s) are missing CPEs. This may result in missing vulnerabilities. You may autogenerate these using: --add-cpes-if-none
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
apk-tools 2.10.6-r0 2.10.7-r0 apk CVE-2021-36159 Critical
busybox 1.31.1-r20 1.31.1-r21 apk CVE-2021-42383 High
busybox 1.31.1-r20 1.31.1-r21 apk CVE-2021-42378 High
busybox 1.31.1-r20 1.31.1-r21 apk CVE-2021-42374 Medium
busybox 1.31.1-r20 1.31.1-r21 apk CVE-2021-42379 High
busybox 1.31.1-r20 1.31.1-r21 apk CVE-2021-42380 High
busybox 1.31.1-r20 1.31.1-r21 apk CVE-2021-42382 High
busybox 1.31.1-r20 1.31.1-r21 apk CVE-2021-42384 High
busybox 1.31.1-r20 1.31.1-r21 apk CVE-2021-42386 High
busybox 1.31.1-r20 1.31.1-r21 apk CVE-2021-42385 High
busybox 1.31.1-r20 1.31.1-r22 apk CVE-2022-28391 High
busybox 1.31.1-r20 1.31.1-r21 apk CVE-2021-42381 High
expat 2.2.9-r1 2.2.10-r2 apk CVE-2022-25236 Critical
expat 2.2.9-r1 2.2.10-r1 apk CVE-2022-23990 High
expat 2.2.9-r1 2.2.10-r0 apk CVE-2022-22822 Critical
expat 2.2.9-r1 2.2.10-r1 apk CVE-2022-23852 Critical
expat 2.2.9-r1 2.2.10-r0 apk CVE-2022-22827 High
expat 2.2.9-r1 2.2.10-r0 apk CVE-2022-22823 Critical
expat 2.2.9-r1 2.2.10-r0 apk CVE-2022-22824 Critical
expat 2.2.9-r1 2.2.10-r2 apk CVE-2022-25235 Critical
expat 2.2.9-r1 2.2.10-r0 apk CVE-2021-45960 High
expat 2.2.9-r1 2.2.10-r0 apk CVE-2021-46143 High
expat 2.2.9-r1 2.2.10-r2 apk CVE-2022-25315 Critical
expat 2.2.9-r1 2.2.10-r0 apk CVE-2022-22825 High
expat 2.2.9-r1 2.2.10-r0 apk CVE-2022-22826 High
expat 2.2.9-r1 2.2.10-r2 apk CVE-2022-25314 High
expat 2.2.9-r1 2.2.10-r2 apk CVE-2022-25313 Medium
krb5-libs 1.18.3-r0 1.18.4-r0 apk CVE-2021-36222 High
krb5-libs 1.18.3-r0 1.18.5-r0 apk CVE-2021-37750 Medium
libcrypto1.1 1.1.1k-r0 1.1.1l-r0 apk CVE-2021-3712 High
libcrypto1.1 1.1.1k-r0 1.1.1n-r0 apk CVE-2022-0778 High
libcrypto1.1 1.1.1k-r0 1.1.1l-r0 apk CVE-2021-3711 Critical
libssl1.1 1.1.1k-r0 1.1.1n-r0 apk CVE-2022-0778 High
libssl1.1 1.1.1k-r0 1.1.1l-r0 apk CVE-2021-3711 Critical
libssl1.1 1.1.1k-r0 1.1.1l-r0 apk CVE-2021-3712 High
libuuid 2.35.2-r0 2.37.3-r0 apk CVE-2021-3996 Medium
libuuid 2.35.2-r0 2.37.4-r0 apk CVE-2022-0563 Medium
libuuid 2.35.2-r0 2.37.3-r0 apk CVE-2021-3995 Medium
ncurses-libs 6.2_p20200523-r0 6.2_p20200523-r1 apk CVE-2021-39537 High
ncurses-terminfo-base 6.2_p20200523-r0 6.2_p20200523-r1 apk CVE-2021-39537 High
ssl_client 1.31.1-r20 1.31.1-r21 apk CVE-2021-42379 High
ssl_client 1.31.1-r20 1.31.1-r21 apk CVE-2021-42383 High
ssl_client 1.31.1-r20 1.31.1-r21 apk CVE-2021-42386 High
ssl_client 1.31.1-r20 1.31.1-r22 apk CVE-2022-28391 High
ssl_client 1.31.1-r20 1.31.1-r21 apk CVE-2021-42381 High
ssl_client 1.31.1-r20 1.31.1-r21 apk CVE-2021-42384 High
ssl_client 1.31.1-r20 1.31.1-r21 apk CVE-2021-42382 High
ssl_client 1.31.1-r20 1.31.1-r21 apk CVE-2021-42380 High
ssl_client 1.31.1-r20 1.31.1-r21 apk CVE-2021-42374 Medium
ssl_client 1.31.1-r20 1.31.1-r21 apk CVE-2021-42378 High
ssl_client 1.31.1-r20 1.31.1-r21 apk CVE-2021-42385 High
xz-libs 5.2.5-r0 5.2.5-r1 apk CVE-2022-1271 High
zlib 1.2.11-r3 1.2.12-r2 apk CVE-2022-37434 Critical
zlib 1.2.11-r3 1.2.12-r0 apk CVE-2018-25032 High
I have a groovy script which calls another script. This script is not found, and in config you can only point to a given script:
WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedClass (file:/usr/share/groovy/lib/groovy-2.4.17.jar) to method java.lang.Object.finalize()
WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedClass
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/scripts/Create.groovy: 21: unable to resolve class TeamResolver
@ line 21, column 21.
String team = new TeamResolver().getAssignmentTeam( applicationName )
^
1 error
Hi.
I am trying to integrate oec with my system.
Json allert from opsgenie looks much better than in marid but i don't have details filed aka extraproperties.
I want to add that fields to my system
Hi.
i am wondering how can i run multiple jobs on one action.
My flow expected to be like
On close:
For some reason there is no official docker image for this repo..
Suggestion:
Add it to Dockerhub.
Right now this has to be installed on a server as a service, so this is not a SDK at all.
Right now to use this service, user has to call send2opsgeie in command, which means it can't be used as a sidecar.
Please provide http(s) apis as OpsGenie Proxy, so that it can be a sidecar or a standalone proxy service.
It would be nice to have a repository for RPM and DEB bases distributions with the latest versions. This would make oec upgrades much easier.
I got update on our account that mermaid is depricated.
Please make a tag, release, and add binary blobs to release page.
Tnx!
I'm forwarding opsgenie snooze action to our internal alertmanager. My flow looks like
I want to send that silence_id to opsgenie activity logs
or an error if it happens.
Looks like there are way how to send an error to opsgenie but no way how to send success.
the only doubt is discardScriptResponse
that set to true
for that request. i've found no way how to change this to false
Also i can use always exit code 1 and message. But that looks ugly and creates unnecessary complications
Hi there,
We're hoping to use the Docker image of OEC.
It looks like the OEC Dockerfile is missing a version label however, and the OEC github repo doesn't as-of-yet use release tagging.
Given this, it's proving difficult to make use of the Dockerfile because the build image can change at any time - something we can't have in production. The only real way for us to prevent this is spin up build infrastructure specificically for OEC, and the publish and manage the versioning ourselves.
It look like quite a number of docker images are published to your dockerhub accounts though 👍
https://hub.docker.com/u/opsgenie
https://hub.docker.com/u/atlassian
On publish of an OEC release to master, it would probably make sense to build, tag, and push the docker image to dockerhub. This would allow for strategic version pinning, and eliminate the burden of OEC consumers having to manage their own infrastructure just to track, control and distribute OEC releases.
Thanks!
Hi,
after pulling the .deb release from the documentation we attempted an install on a security-hardened instance. We encountered some difficulties successfully completing the installation, presumably as a result of the hardening. We've decided to use the docker image instead, however:
As part of the process to debug where the issue(s) reside, I went ahead and did the standard linting for deb packages (see: https://salsa.debian.org/lintian/lintian) to see if I could isolate any problems, and found a number of issues I thought I should pass along:
lintian opsgenie-oec-1.1.1-deb-amd64.deb
Cheers
OEC is leaking file descriptors. lsof
output was full of lines such as the following:
OpsgenieE 2185 79588 opsgenie 938w REG 253,0 489814 1266478 /home/opsgenie/oec/logs/createErr.txt
OpsgenieE 2185 79588 opsgenie 939w REG 253,0 1012227 1255847 /home/opsgenie/oec/logs/closeErr.txt
OpsgenieE 2185 79588 opsgenie 940w REG 253,0 489814 1266478 /home/opsgenie/oec/logs/createErr.txt
OpsgenieE 2185 79588 opsgenie 941w REG 253,0 1012227 1255847 /home/opsgenie/oec/logs/closeErr.txt
OpsgenieE 2185 79588 opsgenie 942w REG 253,0 489814 1266478 /home/opsgenie/oec/logs/createErr.txt
OpsgenieE 2185 79588 opsgenie 943w REG 253,0 489814 1266478 /home/opsgenie/oec/logs/createErr.txt
OpsgenieE 2185 79588 opsgenie 944w REG 253,0 489814 1266478 /home/opsgenie/oec/logs/createErr.txt
OpsgenieE 2185 79588 opsgenie 945w REG 253,0 489814 1266478 /home/opsgenie/oec/logs/createErr.txt
OpsgenieE 2185 79588 opsgenie 946w REG 253,0 489814 1266478 /home/opsgenie/oec/logs/createErr.txt
OpsgenieE 2185 79588 opsgenie 947w REG 253,0 1012227 1255847 /home/opsgenie/oec/logs/closeErr.txt
OpsgenieE 2185 79588 opsgenie 948w REG 253,0 489814 1266478 /home/opsgenie/oec/logs/createErr.txt
OpsgenieE 2185 79588 opsgenie 949w REG 253,0 489814 1266478 /home/opsgenie/oec/logs/createErr.txt
The problem has been identified here:
Lines 52 to 54 in 5e83474
io.MultiWriter
does not implement io.Closer
. Although the buffer.Bytes does not need Closing, the lumberjack logger is an io.Closer
and needs to be closed:I have implemented a quick-fix and sent a pull request.
Hi,
Maybe it would be a good thing to lock the alpine version to a pinned version rather than building from latest?
FROM alpine:latest as base
This would ensure you get reproducible builds.
What do you think?
Hi.
Working with OEC found that it will be pretty helpfull if it will dump received messages. Probably with Extended debug or so on
We have a case where OEC is running on server where python
executable is linked to python2
. In that case, we are unable to run nagios integration as nagios script is not compatible with python2.
At the moment, we modify https://github.com/opsgenie/oec/blob/master/runbook/executor.go#L19 and recompile ourself, but it would be nice if that cold be changed via config file so upgrade path would be simpler.
Is that something that could be done?
Official Guide: https://docs.opsgenie.com/docs/oec-running#running-oec-with-docker
1. Clone the repository with git clone https://github.com/opsgenie/OEC.git
2. Run docker build . -t oec
Result:
$ docker build -t oec .
Sending build context to Docker daemon 19.24MB
Step 1/12 : FROM golang:1.11.4 as builder
---> dd46c1256829
Step 2/12 : ADD https://github.com/golang/dep/releases/download/v0.5.0/dep-linux-amd64 /usr/bin/dep
Downloading [==================================================>] 8.718MB/8.718MB
---> Using cache
---> 4415ded0588e
Step 3/12 : RUN chmod +x /usr/bin/dep
---> Using cache
---> 8b5111a3de85
Step 4/12 : ADD . $GOPATH/src/github.com/opsgenie/oec
---> Using cache
---> 2c6d04c6285d
Step 5/12 : WORKDIR $GOPATH/src/github.com/opsgenie/oec/main
---> Using cache
---> 473df3eae05c
Step 6/12 : RUN export GIT_COMMIT=$(git rev-list -1 HEAD) && dep ensure -v && CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -a -installsuffix cgo -ldflags "-X main.OECCommitVersion=$GIT_COMMIT -X main.OECVersion=1.0.1" -o nocgo -o /oec .
---> Running in 195f7a4c6ea2
could not find project Gopkg.toml, use dep init to initiate a manifest
The command '/bin/sh -c export GIT_COMMIT=$(git rev-list -1 HEAD) && dep ensure -v && CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -a -installsuffix cgo -ldflags "-X main.OECCommitVersion=$GIT_COMMIT -X main.OECVersion=1.0.1" -o nocgo -o /oec .' returned a non-zero code: 1
I would recommend this repo to have tagged releases so we know which version has been tested for container builds, instead of always "master".
Hi,
We are in the process of running OEC on a Kubernetes cluster. In order to do so, we created the following Dockerfile;
# Install tooling
RUN apt-get update \
&& apt-get install -y curl git
# Download sources
RUN mkdir -p $GOPATH/src/github.com/opsgenie
RUN git clone https://github.com/opsgenie/oec.git $GOPATH/src/github.com/opsgenie/oec
# Build binary
WORKDIR $GOPATH/src/github.com/opsgenie/oec/main
RUN export GIT_COMMIT=$(git rev-list -1 HEAD) && \
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -a -installsuffix cgo \
-ldflags "-X main.OECCommitVersion=$GIT_COMMIT -X main.OECVersion=1.0.1" -o nocgo -o /oec .
# Build OEC based on
# https://github.com/opsgenie/oec/blob/master/Dockerfile
#
FROM python:alpine3.12 as base
RUN pip install requests
RUN addgroup -S opsgenie && \
adduser -S opsgenie -G opsgenie && \
apk update && \
apk add --no-cache git ca-certificates && \
update-ca-certificates
COPY --from=builder /oec /opt/oec
RUN mkdir -p /var/log/opsgenie && \
chown -R opsgenie:opsgenie /var/log/opsgenie && \
chown -R opsgenie:opsgenie /opt/oec
COPY scripts /scripts
USER opsgenie
ENTRYPOINT ["/opt/oec"]
And a Helm chart with the following values;
imagePullSecrets:
- name: xxx
oec:
APIKeySecret:
name: opsgenie-apikey
key: api-key
# Config is the opsgenie configuration file
# See: https://docs.opsgenie.com/docs/oec-configuration for more information
config: |
{
"baseUrl": "https://xxx.opsgenie.com/",
"logLevel": "DEBUG",
"globalArgs": [],
"globalFlags": {
"url": "https://xxx/jira",
"username": "oec",
"password": "xxx",
"issueTypeName": "Incident",
"key": "XXX"
},
"actionMappings": {
"createIssue": {
"filepath": "/scripts/JiraServiceDesk/actionExecutor.py",
"sourceType": "local",
"env": [],
"stdout": "/var/log/opsgenie/createIssue.txt"
},
"resolveIssue": {
"filepath": "/scripts/JiraServiceDesk/actionExecutor.py",
"sourceType": "local",
"env": [],
"stdout": "/var/log/opsgenie/resolveIssue.txt"
},
"addComment": {
"filepath": "/scripts/JiraServiceDesk/actionExecutor.py",
"sourceType": "local",
"env": [],
"stdout": "/var/log/opsgenie/addComment.txt"
}
},
"pollerConf": {
"pollingWaitIntervalInMillis": 100,
"visibilityTimeoutInSec": 30,
"maxNumberOfMessages": 10
},
"poolConf": {
"maxNumberOfWorker": 12,
"minNumberOfWorker": 4,
"monitoringPeriodInMillis": 15000,
"keepAliveTimeInMillis": 6000,
"queueSize": 0
}
}
However, when we deploy this - the following FATAL error occurs;
INFO[2020-11-30T13:33:32.093400979Z] OEC commit version is 75c349516ce16838214e2949637f0770e4bfa8ce
WARNING[2020-11-30T13:33:32.093796687Z] chmod /scripts/JiraServiceDesk/actionExecutor.py: operation not permitted
WARNING[2020-11-30T13:33:32.093828124Z] chmod /scripts/JiraServiceDesk/actionExecutor.py: operation not permitted
WARNING[2020-11-30T13:33:32.093845512Z] chmod /scripts/JiraServiceDesk/actionExecutor.py: operation not permitted
INFO[2020-11-30T13:33:32.093869342Z] Visibility timeout cannot be lesser than 15 seconds or greater than 12 hours, default value[30 s.] is set.
INFO[2020-11-30T13:33:32.094102992Z] OEC-metrics serves in http://localhost:7070/metrics.
INFO[2020-11-30T13:33:32.094221808Z] Queue processor is starting.
ERROR[2020-11-30T13:33:32.23385268Z] Queue processor could not get initial token and will terminate.
FATAL[2020-11-30T13:33:32.233899316Z] EOF
Looking at this file, https://github.com/opsgenie/oec/blob/master/queue/processor.go - it expects some kind of token credentials in /v2/integrations/oec/credentials ? but this file is nowhere to be found nor do i see any references to it in the code or documentation.
What are we missing here? Thank you
According to Jfrog Xray scanner detected the following vulnerabilities, is it possible to create new release to resolve them?
||Severity || ID || Component ||Fix Version ||
| critical | CVE-2024-24790 | github.com/golang/go:1.21.5 | 1.21.11, 1.22.4 |
| critical | CVE-2023-49569 | github.com/go-git/go-git/v5:5.2.0 | 5.11.0 |
|High| CVE-2022-21698 | github.com/prometheus/client_golang:1.1.0 | 1.11.1|
|High| CVE-2023-39325 | golang.org/x/net:0.0.0-20201224014010-6772e930b67b | 0.17.0|
|High| CVE-2022-41723 | golang.org/x/net:0.0.0-20201224014010-6772e930b67b | 0.7.0|
|High| CVE-2021-43565 | golang.org/x/crypto:0.0.0-20200622213623-75b288015ac9 | 0.0.0-20211202192323-5770296d904e |
|High| CVE-2021-33194 | golang.org/x/net:0.0.0-20201224014010-6772e930b67b| 0.0.0-20210520170846-37e1c6afe023 |
|High| CVE-2022-27191 | golang.org/x/crypto:0.0.0-20200622213623-75b288015ac9 |0.0.0-20220314234659-1baeb1ce4c0b|
|High| CVE-2022-27664 | golang.org/x/net:0.0.0-20201224014010-6772e930b67b |0.0.0-20220906165146-f3363e06e74c|
|High| CVE-2020-29652 | golang.org/x/crypto:0.0.0-20200622213623-75b288015ac9 |0.0.0-20201216223049-8b5274cf687f |
|High| CVE-2023-49568 | github.com/go-git/go-git/v5:5.2.0 | 5.11.0 |
|High| CVE-2023-44487 | golang.org/x/net:0.0.0-20201224014010-6772e930b67b |0.17.0|
Hi, getting a couple of errors:
INFO[2024-02-22T03:40:24.021287702Z] OEC version is 1.1.4
INFO[2024-02-22T03:40:24.022777905Z] OEC commit version is 48760aef56f137e950e38f278f53f156bd8ffba9
FATAL[2024-02-22T03:40:24.141241201Z] Could not read configuration: ssh: handshake failed: knownhosts: key is unknown
But if I run manually git clone it works fine, and it fills out the known_hosts file.
INFO[2024-02-22T03:53:56.458653756Z] OEC version is 1.1.4
INFO[2024-02-22T03:53:56.459643949Z] OEC commit version is 48760aef56f137e950e38f278f53f156bd8ffba9
FATAL[2024-02-22T03:53:56.901484778Z] Could not read configuration: couldn't find remote ref "refs/heads/master"
After a manual fix for the known_hosts file, tried to run the oec command and got this error. It tries to read from master branch, but our branch name is main. Is there a way to update it without modifying a code?
FROM golang:1.19
COPY ./alert_automation/volumeresize /go/oec/volresize
ARG OEC_VERSION=1.1.4
RUN apt-get update && \
apt-get install -y --no-install-recommends unzip && \
apt-get install -y --no-install-recommends curl && \
apt-get install -y --no-install-recommends python3 python3-pip && \
apt-get clean && rm -rf /var/cache/apt
RUN curl -L https://github.com/opsgenie/oec/releases/download/${OEC_VERSION}/oec-linux-amd64-${OEC_VERSION}.zip -o /tmp/oec.zip && \
unzip /tmp/oec.zip -d /usr/local/bin && \
rm /tmp/oec.zip && \
mkdir -p /var/log/opsgenie && \
mkdir -p /root/.ssh && \
touch /root/.ssh/known_hosts
ENTRYPOINT [ "OpsgenieEdgeConnector" ]
apiVersion: apps/v1
kind: Deployment
metadata:
name: oec-deployment
namespace: oec
labels:
app: oec
spec:
replicas: 1
selector:
matchLabels:
app: oec
template:
metadata:
labels:
app: oec
spec:
nodeSelector:
app: alert-automation
containers:
- name: oec
image: <IMAGE>
imagePullPolicy: Always
command: ["OpsgenieEdgeConnector"]
env:
- name: OEC_CONF_SOURCE_TYPE
value: "git"
- name: OEC_CONF_GIT_URL
value: "[email protected]:some/path.git"
- name: OEC_CONF_GIT_FILEPATH
value: "/alert_automation/config/oec_conf.yaml"
- name: OEC_CONF_GIT_PRIVATE_KEY_FILEPATH
value: "/root/.ssh/id_ed25519"
- name: SSH_KNOWN_HOSTS
value: "/root/.ssh/known_hosts"
- name: OEC_API_KEY
valueFrom:
secretKeyRef:
name: oec-api-key
key: OEC_API_KEY
resources:
limits:
memory: "1000Mi"
cpu: "500m"
requests:
memory: "300Mi"
cpu: "100m"
volumeMounts:
- name: git-ssh-private-key
readOnly: true
mountPath: "/root/.ssh/id_ed25519"
subPath: id_ed25519
volumes:
- name: git-ssh-private-key
secret:
secretName: git-ssh-private-key
defaultMode: 0400
no commits, no releases, no pull request or even answers for the issues for more than a year...
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.