{"id":19726786,"url":"https://github.com/madnificent/docker-ember","last_synced_at":"2025-04-30T00:32:33.641Z","repository":{"id":5561021,"uuid":"53441095","full_name":"madnificent/docker-ember","owner":"madnificent","description":"Docker for ember-cli with supporting tooling","archived":false,"fork":false,"pushed_at":"2024-04-15T19:17:40.000Z","size":192,"stargazers_count":9,"open_issues_count":5,"forks_count":11,"subscribers_count":3,"default_branch":"master","last_synced_at":"2024-10-30T09:37:49.734Z","etag":null,"topics":["developer-tools","docker","ember-cli","emberjs"],"latest_commit_sha":null,"homepage":null,"language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/madnificent.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":"support-scripts","governance":null,"roadmap":null,"authors":null,"dei":null}},"created_at":"2016-03-08T19:58:57.000Z","updated_at":"2024-07-19T08:24:17.000Z","dependencies_parsed_at":"2023-02-13T02:01:23.598Z","dependency_job_id":"ab242a13-8a24-4076-aecc-6554dfb99f7e","html_url":"https://github.com/madnificent/docker-ember","commit_stats":null,"previous_names":[],"tags_count":65,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/madnificent%2Fdocker-ember","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/madnificent%2Fdocker-ember/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/madnificent%2Fdocker-ember/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/madnificent%2Fdocker-ember/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/madnificent","download_url":"https://codeload.github.com/madnificent/docker-ember/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":224192873,"owners_count":17271236,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["developer-tools","docker","ember-cli","emberjs"],"created_at":"2024-11-11T23:36:46.266Z","updated_at":"2024-11-11T23:36:46.404Z","avatar_url":"https://github.com/madnificent.png","language":"Shell","funding_links":[],"categories":[],"sub_categories":[],"readme":"# docker-ember\n\nDocker and tooling for using ember-cli in a reproducable way.\n\n## Getting Started\n### Installation\n\n#### On Linux\nAssuming you have docker set up correctly, simply clone this repository and add the bin folder to your path.\n\n```bash\ngit clone https://github.com/madnificent/docker-ember.git\necho \"export PATH=\\$PATH:`pwd`/docker-ember/bin\" \u003e\u003e ~/.bashrc\nsource ~/.bashrc\n```\n#### On Mac\nWe suggest to use brew installation scripts to account for specific issues related to docker for mac.\nSee: https://github.com/mu-semtech/homebrew-scripts\n\n### Configuration\n#### Picking an Ember Version\n\nThe version of docker-ember can be selected for situations where it is not known, otherwise Docker Ember tries to select the correct version.\n\nWhen visiting a folder which has a Dockerfile with a docker-ember version in it, that version will be used by docker-ember.  This allows fluidly switching between projects.\n\nFor cases where no version can be found, docker-ember's version can be specified in `~/.config/edi/settings` using the `VERSION` variable.\n```bash\nVERSION=\"5.3.0\"\n```\n\nFor one-time use, you can set `EDI_EMBER_VERSION` to the desired version:\n\n```bash\nEDI_EMBER_VERSION=\"5.3.0\" edi ember version\n```\n\nSupported versions are the tags available at [https://hub.docker.com/r/madnificent/ember/tags/](https://hub.docker.com/r/madnificent/ember/tags/).\n\n#### Linux configuration with user namespaces (advised)\n\nBy default `ed*` commands run as root in the docker container, this means newly created files will be owned as root as well. To avoid this you can use user namespaces to map the container's root user to your own user. This requires some configuration and can be done with dockerd running as root (default) or as your user (see [Linux configuration with rootless docker](#linux-configuration-with-rootless-docker)).\n\n\u003e [!NOTE]\n\u003e on ubuntu 16.04 your user needs to part of the docker group so that it has access to `/var/run/docker.sock`\n\nAssuming systemd and access to the `id` command the following steps should suffice:\n\n1. **Create the correct mapping in `/etc/subuid` and `/etc/subgid`**\n    ```bash\n    echo \"$( whoami ):$(id -u):65536\" |  sudo tee -a /etc/subuid\n    echo \"$( whoami ):$(id -g):65536\" |  sudo tee -a /etc/subgid\n    ```\n\n\u003e [!NOTE]\n\u003e Using the above user maps mean that the user `0` (root) inside the container are mapped to your user id on the host, *the id for every user above that is mapped to your-id + their-id*. This means that any containers which run non-root processes could appear to be running as real users on your system. This is unlikely to cause problems unless you have an unusual user configuration.\n\n2. **Adjust ExecStart of docker daemon to include `--userns-remap=ns1`.**\n    For systemd you can use the following command:\n    ```bash\n    systemctl edit docker.service\n    ```\n\n    The config file might look this:\n    ```conf\n    [Service]\n    ExecStart=\n    ExecStart=/usr/bin/dockerd --userns-remap=\"your-user-name\"\n    ```\n\nMore information on user namespaces is available [in the docker documentation](https://docs.docker.com/engine/security/userns-remap/).\n\n#### Linux configuration with rootless docker\n\n\u003e [!NOTE]\n\u003e At this point we advise to use user namespaces instead, though if you have some experience with docker then rootless docker is a bright future.\n\nMore recent versions of Docker can run in 'rootless' mode, running the docker daemon as a normal user instead of root. When running in this mode, the root user inside containers is always mapped to the host user, so no special `subuid` or `subgid` configuration are required. Users inside containers with uids \u003e0 are mapped according to the `subuid` configuration.\n\nThis may cause some issues with other images as some features are not yet supported in rootless.\n\nFor more details and configuration steps, see the [Docker Rootless](https://docs.docker.com/engine/security/rootless) documentation as well as any relevant documentation for your distro (e.g. [Arch Wiki](https://wiki.archlinux.org/title/Docker#Rootless_Docker_daemon)).\n\nWhile not directly needed for docker-ember, many projects make use of ports \u003c 1024, which by default require root to allocate. If you wish to continue with this, follow [the instructions in the documentation](https://docs.docker.com/engine/security/rootless/#exposing-privileged-ports).\n\nUsing `--add-host` is not supported in rootless docker, instead join the desired network and connect directly to the service instead as per [Proxy to a Docker Compose service (advanced)](#proxy-to-a-docker-compose-service-(advanced)).\n\n#### Configuring on Mac\n\nMac uses a login shell when launching the default terminal app, which slightly changes the desired setup.  Sharing the ssh-agent socket currently doesn't work, and thus requires a workaround.\n\n1. **Make your shell read .bashrc**\n\n    Docker for Mac creates files under the right username automatically.  Mac does use a login shell when launching the default terminal app, rather than an interactive shell.  These shells don't read the standard ~/.bashrc file, but rather the ~/.bash\\_profile file.  Make sure the following is present in your ~/.bash\\_profile so ~/.bashrc is always read.\n\n    ```bash\n    if [ -f ~/.bashrc ]; then\n    source ~/.bashrc\n    fi\n    ```\n\n2. **Support the ssh-agent**\n\n    The ssh-agent's socket can't be shared with Docker for Mac at the time of writing.  A common workaround is to use a Docker container in which a new ssh-agent is ran.  We advise the use of the https://github.com/10eTechnology/docker-ssh-agent-forward and have integrated this in the supplied scripts.  On mac, this solution is assumed to be installed.\n\n#### NPM upgrades\nIt's important to note that since NPM v7 peer dependencies are installed by default when executing `npm install`. As of v3.27 the `docker-ember` image contains NPM \u003e= v7.x. Using this version may lead to resolution conflict errors on peer dependencies in existing projects. NPM provides a [`--legacy-peer-deps` flag](https://docs.npmjs.com/cli/v7/using-npm/config#legacy-peer-deps) to make `npm install` behave like in previous versions, not installing peer dependencies by default. This can help teams to gradually fix the peer dependency version conflicts in their project.\n\nThe `--legacy-peer-deps` flag can be enabled project-wide by adding `legacy-peer-deps=true` to `.npmrc`. In that case it's import to copy that file inside your project's Docker build before running `npm install`.\n\nExample Dockerfile:\n```dockerfile\nFROM madnificent/ember\nCOPY package.json .\nCOPY .npmrc .   # \u003c--- this line must be added\nRUN npm install\n```\n\n### Creating a new app using docker-ember\nAll commands (except for `ember serve` which deserves special attention), can be ran through the *edi* command.\n\nLet’s create a new project:\n```bash\nedi ember new my-edi-app\n```\nThis will generate a new application.  Once all dependencies have been installed, we can move into the application folder, and start the ember server:\n```bash\ncd my-edi-app\neds\n```\n\nYou will see the application running.  Moving your browser to *http://localhost:4200*, you will see the `ember-welcome-page`.  Yay! It works \\\\o/\n\nLet’s remove the welcome-page.  As instructed, we’ll remove the `{{welcome-page}}` component from the build.  Open your favorite editor, and update the contents of *application.hbs* to contain the following instead.\n```hbs\n\u003ch1\u003eMy first edi app\u003c/h1\u003e\n\n{{outlet}}\n```\n\nWe can generate new routes with the ember application still running.  Open a new terminal and open the *my-edi-app* folder.  Then generate the route:\n```bash\nedi ember generate route hello-link\n```\n\nEdit the *app/templates/hello-link.hbs* template so it contains the following\n```hbs\n\u003cp\u003eHello!  This is some nested content from my first page.  \u003cLinkTo @route='index'\u003eGo back\u003c/LinkTo\u003e\u003c/p\u003e\n```\n\nand add a link to *app/templates/application.hbs*\n```hbs\n\u003ch1\u003eMy first edi app\u003c/h1\u003e\n\u003cp\u003e\u003cLinkTo @route='hello-link'\u003eHello\u003c/LinkTo\u003e\u003c/p\u003e\n\n{{outlet}}\n```\n\nBoom, we have generated files which we can edit.  Lastly, we’ll install the *ember-cli-sass* addon as an example.\n\n```bash\nedi ember install ember-cli-sass\n```\n\nNow **restart eds** to ensure the ember server picks up the newly installed addon, remove the old *app/styles/app.css* and add a `background-color` to *app/styles/app.scss*\n```scss\nbody {\n  background-color: green;\n}\n```\n\n#### Caveats\n\nThere are some caveats with the use of edi.  First is configuring the ember version.  You can switch versions easily by editing a single file.  Next is configuring the backend to run against.\n\n- Configuring the ember version\n    You may want to have more than one ember version installed when generating new applications.  See [Picking an Ember Version](#picking-an-ember-version)\n\n- Linking to a backend\n    Multiple options exist for proxying to a backend.  When proxying to localhost use `--proxy=http://host/` instead of `--proxy=http://localhost/`.  See [Proxy to a local port (default)](proxy-to-a-local-port-(default)) and [Proxy to a Docker Compose service (advanced)](proxy-to-a-docker-compose-service-(advanced)] for your options.\n\nAnd you're done! Our EmberJS development has become a lot more consistent and maintainable with the use of edi.  We have used it extensively, and have been able to reproduce builds easily in the past year.\n\n*This tutorial has been adapted from Aad Versteden's mu.semte.ch article. You can view it [here](https://mu.semte.ch/2017/03/09/developing-emberjs-with-docker/)*\n\n### Experimental features\n\nSome experimental features have been added which optimize the way the Docker daemon is called.  These features may behave oddly when developing addons.  It may be required to restart certain daemons after using edl, or to disable features when using edl.\n\n#### Live daemon\n\nSome systems take more time than necessary to spin up a new docker daemon.  For these cases, you may choose to keep a daemon alive and send commands to the daemon.  Set `EDI_USE_EDI_DAEMON` to a non-empty string to enable this feature.\n\nNote: You will have to restart the daemon after using edl.\n\n#### Optimize linked modules\n\nThe ember docker links locally developed node modules.  Some optimizations are possible in this regard but they break edl.\n\nWe mount all available node modules in a consistent way when you use edl.  Mounting many volumes may lead to a slow-down on some systems.  You may choose to mount only the used linked modules by setting `EDI_MOUNT_ONLY_USED_LINKED_MODULES` to a non-empty string.\n\nWhen using older versions of node when developing nested node modules the builds may fail because the right node submodules are not included.  This is not the case when the symlinks are removed.  Setting both `EDI_MOUNT_ONLY_USED_LINKED_MODULES` and `EDI_MOUNT_USED_NODE_MODULES_WITHOUT_SYMLINKS` will mount the used node_modules directly.  This may also have a positive performance impact, but we did not run benchmarks.\n\nThese optimizations should be disabled when running edl as edl will not be able to find the addons to link.\n\n#### SSH agent container\n\nWe assume you are running an SSH agent container as mentioned earlier.  If your application never reaches to the outside world using your ssh key, you may disable this feature.\n\nOn Mac, the socket of the native SSH agent can't be shared to the Docker image like we do in Linux.  We assume the necessary tooling is available on Mac to share the SSH agent.  Should you want to disable this feature, set `EDI_SSH_AGENT_CONTAINER` to an empty string.  If you want to force it to be turned on on Linux, then set it to a non-empty string.\n\nWhen you disable this option, your locally running socket will be shared.  When Docker for Mac starts supporting this feature, that will be the superior option.\n\n\u003chr\u003e\n\u003cbr\u003e\n\u003cbr\u003e\n\n## Usage (how-to)\nWe have 4 commands, each for a different use-case.  Run them at the\nroot of your project.\n\n### ed\n\n`ed` is your default friend.  `ed` helps you install npm \u0026 bower\ndependencies, install new ember dependencies and run any other\nnon-interactive ember command.\n```bash\n# Install a dependency\ned ember install ember-cli-coffeescript\n# Install all current node modules\ned npm install\n# Install bower components\ned bower install\n ```\n\n### eds\n`eds` launches the ember server for you.\n\n```bash\n# No nonsense ember server\neds\n```\n\n#### Proxy to a local port (default)\n\nIf you have a service running on a local port (ie: publishing a port through Docker), you can proxy to that host.\n\nProxying is done to the special hostname `host` in this case, which will represent the environment which runs the Docker Ember container.\n\nThe Docker Container itself is a mini virtual machine.  In this virtual machine, the name _localhost_ indicates that little virtual machine.  For example if you're using a [Semantic Works](https://semantic.works/) architecture backend, published on port 80 in a docker compose project, you can connect your development frontend to it as such:\n\n```bash\neds --proxy http://host/\n```\n\nFor instance, to proxy to port `8080` of the machine executing the command:\n\n```bash\n# Proxying to your localhost (note it's been renamed from localhost to host)\neds --proxy=http://host:8080/\n```\n\u003e [!NOTE]\n\u003e The host to proxy to is `host` in this case, not `localhost`\n\n\u003e [!NOTE]\n\u003e This makes use of the default `--add-host` option which may become optional in the future.  For scripting, you may want to run `eds --add-host --proxy=http://host:8080/` instead to be explicit.\n\n#### Proxy to a Docker Compose service (advanced)\n\nProxying directly to a service in a Docker Compose stack without publishing ports.\n\n\u003e [!NOTE]\n\u003e The default option `--add-host` is disabled automatically when using this feature.\n\nTwo parts need to be specified: the docker network where the service can be found, and which service to connect to in that network.  This does not require publishing a port locally.\n\n```bash\n# Proxying to a docker network\neds --network=network-name --proxy=http://service:8080\n```\n\nFor example if you're using a [Semantic Works](https://semantic.works/) architecture backend, published on port 80 in a docker compose project called `my-project`, you could connect your development frontend to it as such:\n\n```bash\neds --network=my-project_default --proxy=http://identifier/\n```\n\n\u003e [!NOTE]\n\u003e This is the only supported method when running [Linux configuration with rootless docker](#linux-configuration-with-rootless-docker)\n\n#### Proxy to an external host\n\nTo proxy to an external host use the `--proxy` option with no extra arguments. Some caveats exists:\n- if the backend uses HTTPS, specify the HTTPS url directly: `eds --proxy=https://semantic.works/`\n- with rootless docker you have to disable the docker network wiring using `-A` option: `eds -A --proxy=https://semantic.works/`\n\n#### Serving on a non default port\n\nIf port 4200 is already taken, `eds` can be ran on a different port.  Both `port` (which can be visited in the browser) as well as `live-reload-port` (for reloading on changes) need to be remapped.\n\n```bash\n# Serving on a non default port\neds --port=4000 --live-reload-port=64000\n```\n\n### edi\n\n`edi` is the interactive version of `ed`.  It can ask you questions\nand you can provide interactive answers.\n```bash\n# Generate a route\nedi ember generate route epic-win\n# Release a new minor version\nedi ember release --minor\n```\n\n### edl\n`edl` is your friend when developing addons. It provides a replacement for `npm link` and `npm unlink` that works in docker-ember. \n```bash\n# Create a global symlink of your addon\ncd your-ember-addon\nedl\n# Use that addon in another project\ncd your-ember-project\nedl your-ember-addon\n# Remove the global symlink of your addon\ncd your-ember-addon\nedl -u\n```\n\n\u003e [!NOTE]\n\u003e `edl` assumes `edi` is available on your PATH\n\n### Building locally\n\nTo build locally in any capacity, run the [release](release) script using the desired ember-cli version.\nExample usage: `./release 4.9.2`\n\nSeveral of the files in this repo are a result of building. See the table below for which files to change:\n\n|    File to change    |             ... for              |\n| -------------------- | -------------------------------- | \n| templates/Dockerfile | for Dockerfile changes           |\n| support-scripts      | for changes in multiple binaries |\n| templates/bin/*      | for changes to specific binaries |\n\n\u003chr\u003e\n\u003cbr\u003e\n\u003cbr\u003e\n\n## Explanations\nOur ember-cli builds have not been as reproducable as we'd have wanted\nthem to be.  Tooling can differ across machines because the operating\nsystems are different, therefore yielding different versions of\nnodejs/iojs or different versions of sass bindings.  The sass bindings\nare what pushed us over the edge to try out Dockers for sharing our\nbuild environment.\n\nWith the advent of user-namespaces in Docker, mounting volumes with\nthe right privileges has become\ntransparent. (see http://www.jrslv.com/docker-1-10/#usernamespacesindocker\nfor some basic info)\n\nThe arguments you need to pass to the Docker run command for it to be\nuseful are too cumbersome, hence we've created scripts to help you\nout.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmadnificent%2Fdocker-ember","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmadnificent%2Fdocker-ember","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmadnificent%2Fdocker-ember/lists"}