I have an reactjs application that I have deploy on my web server.
I build my app (So it's create a build folder) and when I want to start it with ~/.npm-packages/bin/serve -s ./build -l tcp://0.0.0.0:8100 it work (with work dir set to react/, build is here react/build but we can see all source code on my page, that theory not possible in production mode.
If I set the work dir to react/build it return a 404 error.
Inside build folder
It doesn't return any other error unfortunately.
Update: I only stock build folder and it work, but we can always see source code even its in production mode.
If I change to react/build, react/build/static or other, it display 404.
If you are using npm's serve (the default for create-react-app, which I am assuming you are using), that second argument is the directory to serve:
$ serve --help
$ serve} [-l listen_uri [-l ...]] [directory]
By default, serve will listen on 0.0.0.0:5000 and serve the
current working directory on that address.
-s, --single Rewrite all not-found requests to `index.html`
But serve is meant for development serving. It works fine for production of a small static site, but consider another production-proven web server.
Your unminified source should not be kept on a production server, at all. You should deploy just the build files to production.
Related
this is my first deployment, I have gone so far as to create and configure Ubuntu instance on lightsails following official guide. However, I run into problems when instead of an empty project I use my own Django hosting React frontend.
My project works on my computer and if I start up django's production server thorugh manage.py runserver but does not run at all if I use gunicorn to run it with:
gunicorn my_app.wsgi --bind 0.0.0.0:8000 --workers 4
It seems that it cannot find proper filepaths of any static files but I do not undertstand how to configure it to use it since Django already has all the right paths.
One of the errors in the browser console:
Refused to execute http://3.127.76.103/static/rest_framework/js/bootstrap.min.js as script because "X-Content-Type-Options: nosniff" was given and its Content-Type is not a script MIME type.
How can I start fixing it, I do not understand why it does not see the any files.
I have mapped my directory (on host OS) to a directory in docker. When i make changes in host directory, they are refelcted in Docker directory but apps like nodemon or react-hot-reloader do not detect them and hence do not restart. However, hot reloading works fine when i make changes directly within docker. I am running an express app. I have tried two OSs (node:alpine3.13 & node:stretch-slim)for Docker but hot reloading works on neither. I also tried installing inotify-tools on alpine but to no avail
I'm running automated builds on CircleCI of a react app. And a step involves running npm run build and then copying to an S3 bucket to host builds. What I'm seeing is that s3cmd is copying *.css files to my S3 bucket with the wrong MIME type (text/plain) and that when served up this is causing the web application to not work.
I'm running s3cmd version 2.0.2 both locally on my mac (homebrew) and on CircleCI (running inside of a nodejs container, installed via installing pip, setuptools, and installing s3cmd via sudo python setup.py install).
When running locally on my mac, I deploy my app like this:
s3cmd put --recursive -P dist/* s3://$BUCKET
On CircleCI -- I run the exact same command. I have also tried the --guess-mime-type option which seems to have no effect.
The way I determine the MIME type is wrong is like this:
$ s3cmd info s3://$BUCKET/$DEPLOY/static/css/main.a0a90112.css | grep MIME
MIME type: text/plain
When I run the same command after having deployed from my local machine, I get a CSS MIME type.
So what am I doing wrong?
I had this problem with s3cmd rsync (not s3cmd put as in the question) setting files with extension .css as mime type type text/plain. Thanks to the comment above and in it's linked issues, this fixed it:
s3cmd sync --no-mime-magic --guess-mime-type ...
Using
s3 put ...
You can upload all your files excluding css with
--guess-mime-type --no-mime-magic --exclude "*.css"
And then you upload only css with forced mime-type
-m "text/css" --exclude "*" --include "*.css"
I'm now able to run a Dart app using
gcloud --verbosity debug preview app run app.yaml
and also to deploy and run on AppEngine
gcloud --verbosity debug preview app deploy app.yaml
but I haven't found a way to connect a debugger to the Dart app running on the development server.
I found http://dartbug.com/21067 but still couldn't find a way to make it work.
See also https://groups.google.com/a/dartlang.org/forum/#!topic/cloud/OK1nJtg7AjQ
Update 2015-02-27
The app can be run without Docker and then be debugged like any Dart command line application:
Source. https://groups.google.com/a/dartlang.org/d/msg/cloud/zrxgOHFz_lA/q5CdLLQPBAgJ
The API server is part of the App Engine SDK, and we are using it for
running tests in the appengine package. If you look at
https://github.com/dart-lang/appengine/blob/master/tool/run_tests.sh
you will see that it expects the environment variable
APPENGINE_API_SERVER.
The API server is in /platform/google_appengine/api_server.py
and takes a number of arguments. I just tested running it like this:
$ $CLOUD_SDK/platform/google_appengine/api_server.py \ -A
dev~test-application \ --api_port 4444 \ --high_replication \
--datastore_path /tmp/datastore
To run an app engine application outside the normal development server
requires that a number of environment variables are set. This worked
for my application:
$ GAE_LONG_APP_ID=test-application \ GAE_MODULE_NAME=default \
GAE_MODULE_VERSION=version \ GAE_PARTITION=dev \ API_PORT=4444 \
API_HOST=127.0.0.1 \ dart bin/server.dart
In the Dart Editor you cannot set environment variables for each
launch configuration, so they have to be set globally before starting
the Dart Editor. In WebStorm it is possible to have run configuration
specific environment variables.
This simple setup will of cause not support everything the normal
development server support. Some of the issues are:
Only one application at the time as it is always listening on port
8080 (can easily be made configurable) * The users API (mocking this
shouldn't be that difficult) * The modules API * No health-checks
(should not be a problem) * All HTTP headers are direct from the
client (no x-appengine- headers) * The admin web interface is not
available * Probably other stuff as well
This is all experimental, but it is one solution for a simpler
developer setup, which of cause does not match the deployment
environment as closely as the development server.
Running the API Server using Docker is also possible as the image
google/cloud-sdk with the Cloud SDK is on hub.docker.com.
Use the following Dockerfile
FROM google/cloud-sdk EXPOSE 4444 ENTRYPOINT
["/google-cloud-sdk/platform/google_appengine/api_server.py", \
"-A", "dev~test-application", \ "--api_port", "4444", \
"--high_replication", \ "--datastore_path", "/tmp/datastore"]
Build and run
$ docker build -t api_server . $ docker run -d -p 4444:4444 api_server
Change API_HOST above to 192.166.59.103 (of wherever your Docker
containers are) and run.
Regards, Søren Gjesse
Update 2014-11-27
Debugging from DartEditors debugger started working with the bleeding Dart build 1.8.0.edge_042017.
I assume that the next dev build (probably 1.9.0-dev1.0) will include the related fixes as well?
Detailed steps how this works can be found here: https://groups.google.com/a/dartlang.org/d/msg/cloud/OK1nJtg7AjQ/u-GzUDI-0VIJ
Build a custom Docker image with the latest Dart dev build 1.8.0-dev.4.6.
The Dart team is actually preparing an easy way to do this yourself (see https://github.com/dart-lang/dart_docker)
Installe the latest bleeding_edge on the host system (using this script https://gist.github.com/zoechi/d240f56a32ed5649797f or manual download from http://gsdview.appspot.com/dart-archive/channels/be/raw/latest/editor/darteditor-linux-x64.zip)
Add this to the app.yaml file
env_variables:
DBG_ENABLE: 'true'
# disable health-checking because this is so annoying during debugging
vm_health_check:
enable_health_check: False
See How to disable health checking for `gcloud preview app run` for more details about customizing health checking.
Launch the server code of your app with glcoud --verbosity debug app run app.yaml or glcoud --verbosity debug app run app.yaml index.yaml
Wait until the Docker container is ready (check with docker ps if the Command column shows a value starting with /dart_runtime/dart_
Open DartEditor
Open Menu Run > Remote Connection...
Connect to: Command-line VM
Host: localhost if you dont use boot2dockeror the IP address returned by the commandboot2docker ip`
Port: 5005
Select Folder... select the directory which contains the source code of your project.
Click OK
Set breakpoints and continue as usual.
Old
A first step is using the Observatory which includes a browser based debugger UI.
To make this work add the following lines to the app.yaml file
network:
forwarded_ports: ["8181"]
This might be useful as well to make the server.dart wait until we had the chance to set breakpoints using the observatory.
env_variables:
DART_VM_OPTIONS: '--pause-isolates-on-start'
boot2docker gives us the Docker ip (192.168.59.103) and after starting with gcloud preview app run app.yaml we can connect to http://192.168.59.103:8181 which should open the Observatory GUI.
I've upgraded Sencha cmd to v4 and I used to be able to build to a specific archive path and destination path. This was crucial as the build server removes the source code folder and archive path for each build. I had the paths output on the IIS server away from the build server, so that they are never lost.
However, my build process is failing now as the path parameters supplied to the sencha cmd don't do anything.
If I type:
Sencha help app build
I get the following help:
Syntax
sencha app build [options] [environment] \
[destination] \
[archive]
But supplying these parameters has no effect to the location of the output.
Can anyone point me to the documentation which shows if this has changed and how I rectify it. I can't find anything on the their site which shows how to build for production and have it output to separate paths. Also I'd like to know why the Sencha Tools change so much. This wreaks havoc on any existing build systems because things suddenly stop working.
See below:
C:\Development\Projects\IEApp>sencha app build --archive C:\temp\build\IEApp\bui
ldarchive --destination C:\temp\build\IEApp\Destination --environment production
Everything builds ok, but the C:\temp\build folder is empty.
I can not tell you where the doc is, but to get CMD to build to a different directory, this is what I do:
modify the file: .sencha\app\production.properties as follows:
# =============================================================================
# This file provides an override point for default variables defined in
# production.defaults.properties. These properties are only imported when building
# for the "production" environment.
#
# Properties defined in this file take priority over build.properties but are
# only loaded for "production" builds.
# =============================================================================
build.dir=${app.dir}/../../ExtJSApps/dashboard