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
Related
I appreciate help in this matter.
I have the latest images (2.2.0, CA 1.4.8), but I'm getting the error when I'm installing chaincode at the first peer:
failed to invoke chaincode lifecycle, error: timeout expired while executing transaction
I'm working behind a proxy, using a VPN.
I tried to increase the timeouts at the docker config, for all peers:
CORE_CHAINCODE_DEPLOYTIMEOUT=300s
CORE_CHAINCODE_STARTUPTIMEOUT=300s
The process works perfectly up to that point (channel created, peers joined the channel). The chaincode can be installed manually with npm install.
I couldn't find an answer to this anywhere. Can someone provide guidance?
UPDATE: It seems that the chaincode container gets boostrap (and even attributed a random name), but gets stuck at:
+ INPUT_DIR=/chaincode/input
+ OUTPUT_DIR=/chaincode/output
+ cp -R /chaincode/input/src/. /chaincode/output
+ cd /chaincode/output
+ '[' -f package-lock.json -o -f npm-shrinkwrap.json ]
+ npm install --production
I believe it is the proxy blocking npm.
I tried to solve this with:
npm config set proxy proxy
npm config set https-proxy proxy
npm set maxsockets 3
After days of struggling, I've found a solution:
-Had to build a custom fabric nodeenv image, that contained the env variables to setup the npm proxy vars: as in node chaincode instantiate behind proxy. After that, I've setup the following env vars in docker.yaml:
- CORE_CHAINCODE_NODE_RUNTIME=my_custom_image
- CORE_CHAINCODE_PULL=true
Useful! For Chinese users, npmjs may sometimes be disconnected and can build their own instances.
For example, if I use version 2.3.1, Download https://github.com/hyperledger/fabric-chaincode-node/tree/v.2.3.1 Edition. Then enter docker/fabric-nodeenv, modify the Dockerfile, and add a line to modify the warehouse source for npmjs:
RUN npm config set registry http://registry.npm.taobao.org
The entire file is as follows:
ARG NODE_VER=12.16.1
FROM node:${NODE_VER}-alpine
RUN npm config set registry http://registry.npm.taobao.org
RUN apk add --no-cache \
make \
python \
g++;
RUN mkdir -p /chaincode/input \
&& mkdir -p /chaincode/output \
&& mkdir -p /usr/local/src;
ADD build.sh start.sh /chaincode/
Then build a docker image, using the command
docker image build-t whatever/fabric-nodeenv:2.3.
Wait a few minutes, and he'll build the image, and then with docker images, you'll see the image he created
Finally, in peer's configuration file, add in peer-environment
- CORE_CHAINCODE_NODE_RUNTIME=whatever/fabric-nodeenv:2.3
Hope it can help others！
Stack information :
BE : NodeJS App, MongoDB
FE : AngularJS App
Use case :
I am deploying BE(NodeJS) application on AWS ECS along with MongoDB. There is a task definition (AWS) in which there should be both the containers attached so that Mongo container can be linked to the NodeJS container. Mongo container is from docker hub registry registry.hub.docker.com/library/mongo:latest
Please note I have also subscribed to the CloudWatch Logs for the containers.
I am also providing the MONGO_INITDB_ROOT_PASSWORD & MONGO_INITDB_ROOT_USERNAME as new user environment variables.
Problem :
As soon as the service bootstraps NodeJS container, it gets failed with below error.
2019-05-28T14:15:23.208+0000 I CONTROL [main] ERROR: Cannot write pid file to /tmp/docker-entrypoint-temp-mongod.pid: Unknown error
Result :
As a result, mongo is not able to get started and NodeJS app is unable to operate on the db. I want this db operations within container (ECS) as a solution.
Please guide what I am doing wrong here!! Kindly Help!
Why it differs from this answer/question :
Because in my case the application along with MongoDB is running in container environment and container (Node container) is all responsible for bootstrapping it or restarting the mongo service. Also, the error I am facing is Unknown Error.
EDIT :
Dockerfile
FROM node:8-alpine
# Create app directory
WORKDIR /usr/src/app
# Install app dependencies
# A wildcard is used to ensure both package.json AND package-lock.json are copied
# where available (npm#5+)
COPY package*.json ./
RUN npm install
# RUN npm audit
# Bundle app source
#COPY . /usr/src/app
COPY . .
EXPOSE 9000
CMD [ "npm", "start" ]
I have webpack frontend application that have config file (config/default.json). I read this with config-webpack. My config file should change between environments (staging/production/etc)
I have CI pipeline that build my js code, minimize and package in docker image of nginx to be published in docker registry (inmutable|agnostic of my config file).
My docker container must be initialize env key with execution value
ENVIRONMENT=staging|production|stress
In docker container i have connection to secrets store and retrieve config data for my execution ENVIRONMENT.
Doing all the build on container start is expensive.
I need post process my build to attach config/default.json to webpack bundle. No build all my project.
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'm using Windows 7x64, gcloud installed version
Google Cloud SDK 0.9.71
app 2015.07.24
app-engine-java 1.9.24
app-engine-python 1.9.24
app-engine-python-extras 1.9.21
bq 2.0.18
bq-win 2.0.18
core 2015.07.24
core-win 2015.07.24
gcloud 2015.07.24
gsutil 4.13
gsutil-win 4.13
preview 2015.07.24
windows-ssh-tools 2015.06.02
I'm trying to run on preview and deploy the tutorial example from here. Note that app.yaml from this example has "nodejs" set as runtime.
After running command
gcloud preview app run --host localhost:8080 app.yaml
I get
RuntimeError: Unknown runtime 'nodejs'; supported runtimes are 'custom', 'go', 'java', 'java7', 'php', 'php55', 'python, 'python27', 'vm'.
If I put "vm" for runtime it wants to use docker, which doesn't work for me either and I wanted to use the option to do this without docker anyhow.
If I put "custom" for runtime in yaml file I get:
ValueError: The --custom_entrypoint flag must be set for custom runtimes
Example given in the help output for this switch is the following
--custom_entrypoint="gunicorn -b localhost:{port} mymodule:application"
I tried with this, best guess
gcloud preview app run --custom_entrypoint="nodejs -b localhost:{8080} mymodule:application" app.yaml
and got this
ERROR: Argument [--custom_entrypoint=nodejs -b localhost:{8080} mymodule:application] is not a valid deployable file.
ERROR: (gcloud.preview.app.run) Errors occurred while parsing the App Engine app configuration.
Thanks for your time.
The gcloud command seems to be undergoing some changes, so this question seems no longer valid, since we're meant to run dev_appserver.py instead of gcloud to run devserver processes; you can also just straight-up run the node server, or even use docker to build the image from your dockerfile and run that as a container.
If running from dev_appserver.py, make sure you have runtime: custom and a Dockerfile sourcing FROMgcr.io/google_appengine/nodejs, since dev_appserver.py currently raises:
RuntimeError: Unknown runtime 'nodejs'; supported runtimes are 'custom', 'go', 'java', 'java-compat', 'java7', 'php55', 'python', 'python-compat', 'python27'.