I have a Dockerfile that uses an ubuntu base image and installs a bunch of dependencies with apt-get and dpkg. Then it copies some javascript files and runs a node app. The node app spawns a child process and executes xvfb-run selenium-standalone start.
If I build the docker image with --no-cache and run it using docker run -i -t <image id> my app starts and connects to the selenium server immediately. If I kill the container using CTRL-C or docker stop <container id> and then run the exact same docker run command as above, my app starts as normal, but cannot connect to the selenium server. If I leave it alone, five minutes later, it will connect properly on its own. It behaves this way every time I run docker run until I do a clean image build.
Changing a node source file and rebuilding mostly from cache does not alter this behavior. I've repeated the process several times and it's always the same.
I can't figure out how the behavior can change from one docker run to the next, if the same image is used. Where is the shared state?
Log when working:
gulp run
22:42:31.541 INFO - Launching a standalone Selenium Server
Setting system property webdriver.chrome.driver to /usr/lib/node_modules/selenium-standalone/.selenium/chromedriver/2.16-x64-chromedriver
22:42:31.579 INFO - Java: Oracle Corporation 24.79-b02
22:42:31.579 INFO - OS: Linux 3.18.5-tinycore64 amd64
22:42:31.594 INFO - v2.46.0, with Core v2.46.0. Built from revision 87c69e2
22:42:31.676 INFO - Driver provider org.openqa.selenium.ie.InternetExplorerDriver registration is skipped:
registration capabilities Capabilities [{platform=WINDOWS, ensureCleanSession=true, browserName=internet explorer, version=}] does not match the current platform LINUX
22:42:31.676 INFO - Driver class not found: com.opera.core.systems.OperaDriver
22:42:31.677 INFO - Driver provider com.opera.core.systems.OperaDriver is not registered
[22:42:31] Using gulpfile /opt/app/gulpfile.js
[22:42:31] Starting 'run'...
[22:42:31] Finished 'run' after 1.29 ms
Started App.
22:42:31.764 INFO - RemoteWebDriver instances should connect to: http://127.0.0.1:4444/wd/hub
22:42:31.764 INFO - Selenium Server is up and running
Selenium started
2015-08-19T22:42:32.445Z Starting app on port: 8000
Logs when not working are exactly the same except missing the RemoteWebDriver, 'Selenium Server is up and running', and 'Selenium started.' lines.
Try removing the container instead of just stopping it:
docker stop <container id>
docker rm <container id>
Related
I have an issue using Minikube with rootless docker.
I recently upgraded my Debian 10 to a Debian 11 with a 5.10.0-16-amd64 kernel version.
Then I have set up a rootless Docker, and its currently working well.
I have followed the documentation of Kubernetes about rootless docker.
But I am facing an error :
🤦 StartHost failed, but will try again: creating host: create: creating: create kic node: container name "minikube": log: 2022-08-03T16:19:15.374997860Z + echo 'INFO: enabling containerd-fuse-overlayfs service'
2022-08-03T16:19:15.375006741Z INFO: enabling containerd-fuse-overlayfs service
2022-08-03T16:19:15.375013843Z + systemctl enable containerd-fuse-overlayfs
2022-08-03T16:19:15.398783149Z Failed to enable unit, unit containerd-fuse-overlayfs.service does not exist.: container exited unexpectedly
So I search on the Internet and found this Github repository explaining how to install containerd-fuse-overlayfs.service that should resolve my problem.
I did not understand well the first option, so I have chosen to use the second option.
When I run the containerd-rootless-setuptool.sh install command (after installed them into /usr/bin). But I got an error too:
mount: /tmp/tmp.aecGG0JEwg/m: permission denied.
[rootlesskit:child ] error: command [mount -t overlay -o lowerdir=/tmp/tmp.aecGG0JEwg/l,upperdir=/tmp/tmp.aecGG0JEwg/u,workdir=/tmp/tmp.aecGG0JEwg/w overlay /tmp/tmp.aecGG0JEwg/m] exited: exit status 32
[rootlesskit:parent] error: child exited: exit status 32
[WARNING] Overlayfs is not enabled, consider installing fuse-overlayfs snapshotter (`/usr/bin/containerd-rootless-setuptool.sh install-fuse-overlayfs`), or see https://rootlesscontaine.rs/how-it-works/overlayfs/ to enable overlayfs.
So I decided to execute the next command anyway :
$ containerd-rootless-setuptool.sh install-fuse-overlayfs
containerd-fuse-overlayfs-grpc (https://github.com/containerd/fuse-overlayfs-snapshotter) needs to be present under $PATH
But I do not understand the error.
Anyone got an idea ? Thank you :)
I have a packer file to deploy Centos 7 using vSphere-Iso builder that works Ok when executed directly on a linux server but when I try to run the same packer file using a gitlab-runner it fails as it does not wait until the OS is installed. It fails after waiting for 1 minute but if I run the packer command with -on-error=run-cleanup-provisioner the OS install finish succesuflly so clear the issue is that packer is just not waiting.
2021/07/20 12:02:40 packer.io plugin: [INFO] Waiting for IP, up to total timeout: 30m0s, settle timeout: 5m0s
==> vsphere-iso.autogenerated_1: Waiting for IP...
==> vsphere-iso.autogenerated_1: Clear boot order...
==> vsphere-iso.autogenerated_1: Power off VM...
==> vsphere-iso.autogenerated_1: Destroying VM...
2021/07/20 12:03:12 [INFO] (telemetry) ending
==> Wait completed after 1 minute 2 seconds
2021/07/20 12:03:12 machine readable: error-count []string{"1"}
==> Some builds didn't complete successfully and had errors:
My boot command is the following as I do not use DHCP.
boot_command = ["<up><tab> text inst.ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/vmware-ks.cfg ip=10.118.12.117::10.118.12.1:255.255.255.0:{{ .Name }}.localhost:ens192:none<enter><wait>"]
I have tested using options like ssh_host, ip_wait_address, ip_settle_timeout, ssh_wait_timeout, pause_before_connecting but nothing seems to work.
As I said, the same packer pkr.hcl file works OK if run it manually on a regular linux but not on my gitlab-runner that is a runner installed directly on my Gitlab server (Yes, I know is not the best practice but I only use the runner for this task)
Packer versions 1.7.2 and 1.7.3 tested, gitlab-runner 14.0.0 and 14.0.1 tested.
Managed to make it work by changing the las wait on my boot command for wait5m. This will give the OS enough time to get installed and the VM rebooted.
New boot command boot_command = ["<up><tab> text inst.ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/vmware-ks.cfg ip=10.118.12.117::10.118.12.1:255.255.255.0:{{ .Name }}.localhost:ens192:none<enter><wait5m>"]
All the other wait options from packer are no longer needed with this boot command.
Doing some test I managed to make it work as well by creating a Firewall drop rule for the VM just after the kickstar file was loaded and removing the FW rules once the OS was installed. Definitelly, packer is just ignoring all the wait machanism native to packer when running on the gitlab-runner
EDIT: After having the same issue with my Windows Templates y tested using a different gitlab-runner installed on a different server instead of the one in the same gitlab server and it worked perfectly with my initial contifiguration for both, windows and centos.
I want to Containerize my Nuxt.js application. I could write my own Dockerfile (as mentioned in the Nuxt.js Google Cloud Run docs for example), but as Cloud Native Buildpacks are here to free us from the need to write those over and over again I wanted to simply use Paketo.io to build a Container from my Nuxt.js app.
I ran
pack build microservice-ui-nuxt-js --path . --builder paketobuildpacks/builder:base
and a Container was created successfully. Here's the full log:
$ pack build microservice-ui-nuxt-js --path . --builder paketobuildpacks/builder:base
base: Pulling from paketobuildpacks/builder
Digest: sha256:3e2ee17348bd901e7e0748e0e1ddccdf8a602b624e418927145b5f84ca26f264
Status: Image is up to date for paketobuildpacks/builder:base
base-cnb: Pulling from paketobuildpacks/run
Digest: sha256:b6b1612ab2dfa294514fff2750e8d724287f81e89d5e91209dbdd562ed7f7daf
Status: Image is up to date for paketobuildpacks/run:base-cnb
===> DETECTING
4 of 7 buildpacks participating
paketo-buildpacks/ca-certificates 2.2.0
paketo-buildpacks/node-engine 0.4.0
paketo-buildpacks/npm-install 0.3.0
paketo-buildpacks/npm-start 0.2.0
===> ANALYZING
Previous image with name "microservice-ui-nuxt-js" not found
===> RESTORING
===> BUILDING
Paketo CA Certificates Buildpack 2.2.0
https://github.com/paketo-buildpacks/ca-certificates
Launch Helper: Contributing to layer
Creating /layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper
Paketo Node Engine Buildpack 0.4.0
Resolving Node Engine version
Candidate version sources (in priority order):
-> ""
<unknown> -> ""
Selected Node Engine version (using ): 14.17.0
Executing build process
Installing Node Engine 14.17.0
Completed in 5.795s
Configuring build environment
NODE_ENV -> "production"
NODE_HOME -> "/layers/paketo-buildpacks_node-engine/node"
NODE_VERBOSE -> "false"
Configuring launch environment
NODE_ENV -> "production"
NODE_HOME -> "/layers/paketo-buildpacks_node-engine/node"
NODE_VERBOSE -> "false"
Writing profile.d/0_memory_available.sh
Calculates available memory based on container limits at launch time.
Made available in the MEMORY_AVAILABLE environment variable.
Paketo NPM Install Buildpack 0.3.0
Resolving installation process
Process inputs:
node_modules -> "Not found"
npm-cache -> "Not found"
package-lock.json -> "Found"
Selected NPM build process: 'npm ci'
Executing build process
Running 'npm ci --unsafe-perm --cache /layers/paketo-buildpacks_npm-install/npm-cache'
Completed in 14.988s
Configuring launch environment
NPM_CONFIG_LOGLEVEL -> "error"
Configuring environment shared by build and launch
PATH -> "$PATH:/layers/paketo-buildpacks_npm-install/modules/node_modules/.bin"
Paketo NPM Start Buildpack 0.2.0
Assigning launch processes
web: nuxt start
===> EXPORTING
Adding layer 'paketo-buildpacks/ca-certificates:helper'
Adding layer 'paketo-buildpacks/node-engine:node'
Adding layer 'paketo-buildpacks/npm-install:modules'
Adding layer 'paketo-buildpacks/npm-install:npm-cache'
Adding 1/1 app layer(s)
Adding layer 'launcher'
Adding layer 'config'
Adding layer 'process-types'
Adding label 'io.buildpacks.lifecycle.metadata'
Adding label 'io.buildpacks.build.metadata'
Adding label 'io.buildpacks.project.metadata'
Setting default process type 'web'
Saving microservice-ui-nuxt-js...
*** Images (5eb36ba20094):
microservice-ui-nuxt-js
Adding cache layer 'paketo-buildpacks/node-engine:node'
Adding cache layer 'paketo-buildpacks/npm-install:modules'
Adding cache layer 'paketo-buildpacks/npm-install:npm-cache'
Successfully built image microservice-ui-nuxt-js
Now running
docker run --rm -i --tty -p 3000:3000 microservice-ui-nuxt-js
i hoped to see my app inside the Browser at http://localhost:3000. But no luck! My app doesn't seem to be fully running:
Although my console looks good:
What am I missing?
I read about the HOST variable in this post , which the whole problem is about! And then I also found this answer, since I now knew what to look for. The Nuxt.js configuration docs state it also:
By default, the Nuxt.js development server host is localhost which is
only accessible from within the host machine. In order to view your
app on another device you need to modify the host.
And the crucial config is mentioned also:
Host '0.0.0.0' is designated to tell Nuxt.js to resolve a host
address, which is accessible to connections outside of the host
machine (e.g. LAN)
So all we have to do is to define a Docker environment variable --env "HOST=0.0.0.0" and run the Paketo build Container like this:
docker run --rm -i --tty --env "HOST=0.0.0.0" -p 3000:3000 microservice-ui-nuxt-js
Now the Browser should also show our app at http://localhost:3000:
You can try it yourself using the GitHub Container Registry published image of the example project:
docker run --rm -i --tty --env "HOST=0.0.0.0" -p 3000:3000 ghcr.io/jonashackt/microservice-ui-nuxt-js:latest
I have a docker image containing an NodeJS app. The Dockerfile is:
FROM node:8
WORKDIR /app
ADD . /app
RUN npm install
EXPOSE 80
ENTRYPOINT [ "/bin/sh", "./start.sh" ]
The start.sh script is:
#!/bin/bash
...
echo "Starting application"
npm start
I'm able to launch and test the image manually:
$ gcloud docker -- run -it --rm my-container
...
Starting application
...
> node index.js
...
The same container is used by a kubernetes deployment:
apiVersion: extensions/v1beta1
kind: Deployment
...
spec:
...
template:
...
spec:
containers:
- image: my-container
...
The container starts, the start.sh script is correctly executed but it terminates and the container goes into a CrashLoopBackOff loop.
After inspecting the pod manually:
kubectl exec -ti my-pod -- bash
I have no name!#my-pod:/app# cat /etc/passwd
... empty response
-> It appears that somehow there are no system users on the container, which makes most commands (like npm) fail silently and terminate the container
I have also tried, without success:
deleting the pod
deleting and re-creating the deployment
running the node image with the node user -> unable to find user node: no matching entries in passwd file
Last note: I actually have many deployments (using the same template with just a different name) which are running fine with an image that was built a few days ago with the same source code.
For some deployments, it actually worked after manually deleting the pod and letting kubernetes recreate it.
Any ideas?
Edit 18/01/2018 I have tried rebuilding an image with the same source code that old working images use, without success. I have also tried a simpler Dockerfile:
FROM node:8
USER node
But I still get an error related to the fact that no users seem to be there:
Error response from daemon: {"message":"linux spec user: unable to find user node: no matching entries in passwd file"}
I have checked with the docker-node guys, the image hasn't changed recently. Could it be related to kubernetes changes? Keep it mind that my images do run when I run them manually with the docker command.
I tried to reproduce your issue, but didn't get it to fail in anything like the same fashion. I made a dummy express app and stuck it on github that matches your example above, and then invoked it into a local minikube instance I had. The base image size is reasonably large, but it started up just fine.
I had to interpret what was happening within npm start for your example since you didn't specify, but you can see my package.json, which I suspect is pretty close to what you're doing based on the description.
When I fire this up:
git clone https://github.com/heckj/dummyexpress
cd dummyexpress
kubectl apply -f deploy/
The I got a running instance right off the bat:
NAME READY STATUS RESTARTS AGE
dummynodeapp-7788b95497-tkw2s 1/1 Running 0 1d
And the logs show pretty much what you'd expect:
**kubectl log dummynodeapp-7788b95497-tkw2s**
W0117 19:41:00.986498 20648 cmd.go:353] log is DEPRECATED and will be removed in a future version. Use logs instead.
Starting application
> blah#1.0.0 start /app
> node index.js
Example app listening on port 3000!
My guess is that you've got something going awry within your npm start execution, so I'd recommend fiddling with that aspect of your deployment and see if you can't resolve it that way.
Well as #heckj pointed out, it was a Docker issue on my kubernetes cluster. I updated the cluster from 1.6.13-gke.1 to v1.7.12-gke.0 and the pods worked fine again. I'm not sure what Docker version was used since there's another kubernetes bug that is preventing me from seeing it.
I want to run appium scripts in parallel on multiple devices but always the second node fails to connect to the selenium server.
This is my selenium server logs which starts and registers perfectly
D:\Appium>java -jar selenium-server-standalone-2.52.0.jar -port 4444 -role hub m
axInstances=2 maxSession=2 -timeout 30000
15:17:45.215 INFO - Launching Selenium Grid hub
2016-02-25 15:17:45.810:INFO::main: Logging initialized #732ms
15:17:45.818 INFO - Will listen on 4444
15:17:45.856 INFO - Will listen on 4444
2016-02-25 15:17:45.859:INFO:osjs.Server:main: jetty-9.2.z-SNAPSHOT
2016-02-25 15:17:45.879:INFO:osjsh.ContextHandler:main: Started o.s.j.s.ServletC
ontextHandler#b0ed20{/,null,AVAILABLE}
2016-02-25 15:17:45.893:INFO:osjs.ServerConnector:main: Started ServerConnector#
76c8cd{HTTP/1.1}{0.0.0.0:4444}
2016-02-25 15:17:45.894:INFO:osjs.Server:main: Started #816ms
15:17:45.894 INFO - Nodes should register to http://10.51.25.88:4444/grid/regist
er/
15:17:45.894 INFO - Selenium Grid hub is up and running
15:18:13.259 INFO - Registered a node http://10.51.25.88:4724
15:18:25.289 INFO - Marking the node http://10.51.25.88:4724 as down: cannot rea
ch the node for 2 tries
This is my Json file to create node and set capabilites
{"capabilities":[{"deviceName":"0009aec74c7a5f","browserName":"chrome","maxInstances":1,"version":"4.1.2","platform":"ANDROID"}],"configuration":{"proxy":"org.openqa.grid.selenium.proxy.DefaultRemoteProxy","cleanUpCycle":2000,"port":4724,"host":"10.51.25.88","maxSession":1,"hubHost":"10.51.25.88","registerCycle":5000,"hubPort":4444,"timeout":30000,"url":"http:\/\/10.51.25.88:4724\/wd\/hub","register":true}}
Hence in the similar way when I try to connect my second appium node it fails to register in appium grid without any command prompt error logs
I have two physical devices connected through USB and devices detected through adb.I am using the latest version of Appium 1.4 and the latest selenium standalone server jar file 2.52.
I am able to register my appium node to selenium server for every first node , either of the device , but when I try to connect my second appium node It fails to connect closing the command promt without giving any error logs.
This same commands and configuration used to work for previous version of Appium (about one year Old), but for the new Appium version second node is not getting registered.
Is there any alternative method to register appium node to selenium grid , or Is there something I am missing above ?
I have built library that generates .json and .bat file for each Appium node. It is tested well and work so cool. So I believe you are missing boot strapping port number to connect another instance of Appium.
Json File:
{
"capabilities":
[
{
"DeviceManufacturer":"LGE",
"DeviceModel":"Nexus 5",
"DeviceOS":"Android",
"OSVersion":"6.0.1",
"DeviceType":"Real",
"deviceName":"038d1797094778a8",
"browserName":"Real_LGE_Nexus 5_Android_6.0.1",
"platform":"Android"
}],
"configuration":
{
"nodeTimeout":120,
"port":4723,
"hubPort":4444,
"proxy": "org.openqa.grid.selenium.proxy.DefaultRemoteProxy",
"url":"http://192.168.1.246:4723/wd/hub",
"hub": "192.168.1.246:4444/grid/register",
"hubHost":"192.168.1.246",
"nodePolling":2000,
"registerCycle":10000,
"register":true,
"cleanUpCycle":2000,
"timeout":30000,
"maxSession":5
}
}
You must be observing that I am using multiple capabilities but I am using all of them by overriding matches method of org.openqa.grid.internal.utils.DefaultCapabilityMatcher class. so when I call main method of org.openqa.grid.selenium.GridLauncher class. I am keeping my overriding jar in same class path and It worked for customizing matching node.
.bat file:
Notice this in .bat file -> --bootstrap 6024
node.exe "C:\Program Files (x86)\Appium\node_modules\appium\bin\appium.js" --address 192.168.1.132 --port 4830 --bootstrap 4830 -U 038d1797094778a8 --nodeconfig D:\MobileBaseProjectRepository\Grid\Node\nodeConfig_192.168.1.132_2.json --session-override
so, coming back to your question use --bootstrap 6024 while invoking appium node, you will through.