From 5fca461b312175aacf2a8e113280cb323e912238 Mon Sep 17 00:00:00 2001 From: James Drummond Date: Mon, 16 Jan 2017 13:18:16 -0600 Subject: [PATCH] Remove docs which are now located at che-docs. (#3580) * Remove docs which are now located at che-docs. * Add dependency information into CONTRIBUTING.md * Added docs/README.md to point to new repo. Signed-off-by: James Drummond jdrummond@codenvy.com --- CONTRIBUTING.md | 9 + docs/README.md | 3 +- docs/_config.yml | 110 -- docs/_data/artik.yml | 15 - docs/_data/docs.yml | 78 -- docs/_data/openshift.yml | 4 - docs/_data/tutorials.yml | 25 - docs/_docs/artik-ide-plugin/artik-api-docs.md | 20 - .../artik-apisdk-management.md | 11 - docs/_docs/artik-ide-plugin/artik-config.md | 8 - docs/_docs/artik-ide-plugin/artik-docker.md | 9 - .../artik-ide-plugin/artik-download-ide.md | 32 - docs/_docs/artik-ide-plugin/artik-network.md | 15 - docs/_docs/artik-ide-plugin/artik-proxies.md | 13 - .../artik-ide-plugin/artik-release-notes.md | 48 - .../_docs/artik-ide-plugin/artik-start-mac.md | 161 --- .../artik-ide-plugin/artik-start-windows.md | 222 ---- .../artik-tutorial-blink-led.md | 43 - .../artik-usb-connection-setup.md | 32 - .../artik-ide-plugin/artik-wireless-setup.md | 8 - .../chedir-chefiles.md | 147 --- .../chedir-factories.md | 19 - .../chedir-getting-started.md | 36 - .../chedir-installation.md | 54 - .../chedir-project-setup.md | 24 - .../chedir-portable-workspaces/chedir-ssh.md | 13 - .../chedir-up-and-down.md | 35 - .../chedir-portable-workspaces/chedir-why.md | 13 - docs/_docs/index.html | 90 -- .../openshift-plugin/openshift-config.md | 60 - .../openshift-plugin/openshift-user-guide.md | 84 -- docs/_docs/setup/che-setup-bitnami.md | 74 -- docs/_docs/setup/che-setup-cli.md | 213 ---- docs/_docs/setup/che-setup-configuration.md | 283 ----- docs/_docs/setup/che-setup-docker.md | 240 ---- .../che-setup-getting-started-saas-cloud.md | 24 - docs/_docs/setup/che-setup-getting-started.md | 272 ---- docs/_docs/setup/che-setup-glossary.md | 45 - docs/_docs/setup/che-setup-intro.md | 85 -- docs/_docs/setup/che-setup-managing.md | 115 -- docs/_docs/tutorials/tutorial-android.md | 53 - .../tutorials/tutorial-che-and-appfog.md | 9 - docs/_docs/tutorials/tutorial-che-in-che.md | 77 -- docs/_docs/tutorials/tutorial-cuba.md | 29 - docs/_docs/tutorials/tutorial-ftpsftp.md | 23 - docs/_docs/tutorials/tutorial-gae.md | 31 - docs/_docs/tutorials/tutorial-gradle.md | 37 - docs/_docs/tutorials/tutorial-java.md | 20 - docs/_docs/tutorials/tutorial-laravel.md | 32 - docs/_docs/tutorials/tutorial-maven.md | 135 -- docs/_docs/tutorials/tutorial-meteor.md | 68 - .../_docs/tutorials/tutorial-multi-machine.md | 144 --- docs/_docs/tutorials/tutorial-nodejs.md | 105 -- docs/_docs/tutorials/tutorial-php.md | 100 -- docs/_docs/tutorials/tutorial-platformio.md | 30 - docs/_docs/tutorials/tutorial-rails.md | 36 - docs/_docs/tutorials/tutorial-sourcegraph.md | 35 - docs/_docs/tutorials/tutorial-spring-boot.md | 34 - docs/_docs/tutorials/tutorial-subversion.md | 41 - docs/_docs/tutorials/tutorial-swing.md | 39 - docs/_docs/tutorials/tutorial-tomee.md | 39 - docs/_docs/tutorials/tutorial-vaadin.md | 38 - docs/_docs/tutorials/tutorial-wordpress.md | 71 -- .../server-api-projects.md | 24 - .../server-build-run.md | 19 - .../server-create-workspaces.md | 21 - .../server-events.md | 27 - .../server-project-types.md | 18 - .../server-rest-api.md | 52 - .../server-stack.md | 108 -- .../server-websocket-api.md | 8 - docs/_docs/use-che-as-an-ide/ide-build.md | 39 - docs/_docs/use-che-as-an-ide/ide-commands.md | 78 -- docs/_docs/use-che-as-an-ide/ide-debug.md | 73 -- docs/_docs/use-che-as-an-ide/ide-docker.md | 59 - .../use-che-as-an-ide/ide-editor-settings.md | 33 - docs/_docs/use-che-as-an-ide/ide-electron.md | 41 - docs/_docs/use-che-as-an-ide/ide-git-svn.md | 84 -- .../use-che-as-an-ide/ide-import-a-project.md | 19 - .../use-che-as-an-ide/ide-intellisense.md | 36 - docs/_docs/use-che-as-an-ide/ide-previews.md | 14 - docs/_docs/use-che-as-an-ide/ide-projects.md | 26 - docs/_docs/use-che-as-an-ide/ide-run.md | 60 - docs/_docs/use-che-as-an-ide/ide-sharing.md | 72 -- docs/_docs/use-che-as-an-ide/ide-ssh.md | 91 -- docs/_docs/use-che-as-an-ide/ide-sync.md | 99 -- .../ws-admin-intro.md | 45 - .../workspace-administration/ws-agents.md | 51 - .../ws-data-model-samples.md | 163 --- .../ws-data-model-stacks.md | 443 ------- .../workspace-administration/ws-machines.md | 66 - .../workspace-administration/ws-recipes.md | 207 ---- .../workspace-administration/ws-samples.md | 47 - .../workspace-administration/ws-stacks.md | 120 -- .../ws-volume-mounts.md | 61 - .../write-che-ide-plugins/plugins-actions.md | 414 ------- .../plugins-assemblies.md | 204 --- .../plugins-calling-workspace-apis.md | 62 - .../plugins-che-properties.md | 51 - .../plugins-code-editors.md | 391 ------ .../plugins-create-and-build-extensions.md | 354 ------ .../plugins-dependency-injection-basics.md | 135 -- .../plugins-embed-htmljs.md | 114 -- .../plugins-helloworld-extension.md | 307 ----- .../plugins-introduction.md | 62 - .../plugins-java-class-reference.md | 19 - .../plugins-native-access-to-the-workspace.md | 88 -- .../write-che-ide-plugins/plugins-parts.md | 230 ---- .../plugins-project-types.md | 345 ------ .../plugins-serverworkspace-access.md | 251 ---- .../plugins-setup-che-workspace.md | 236 ---- .../write-che-ide-plugins/plugins-themes.md | 100 -- docs/_includes/analytics.html | 30 - docs/_includes/anchor_links.html | 33 - docs/_includes/base.html | 6 - docs/_includes/default.html | 20 - docs/_includes/docs_contents.html | 27 - docs/_includes/docs_contents_mobile.html | 16 - docs/_includes/docs_option.html | 7 - docs/_includes/docs_ul.html | 20 - docs/_includes/error.html | 23 - docs/_includes/footer.html | 15 - docs/_includes/header-github-io.html | 15 - docs/_includes/header.html | 16 - docs/_includes/news.html | 19 - docs/_includes/news_contents.html | 33 - docs/_includes/news_contents_mobile.html | 11 - docs/_includes/news_item.html | 25 - docs/_includes/page.html | 18 - docs/_includes/primary-nav-items.html | 32 - docs/_includes/section_nav.html | 44 - docs/_includes/top.html | 16 - docs/_layouts/artik.html | 30 - docs/_layouts/default.html | 28 - docs/_layouts/docs.html | 29 - docs/_layouts/error.html | 35 - docs/_layouts/github-io.html | 49 - docs/_layouts/news.html | 19 - docs/_layouts/news_item.html | 27 - docs/_layouts/openshift.html | 30 - docs/_layouts/page.html | 18 - docs/_layouts/tutorials.html | 30 - docs/_sass/_font-awesome.scss | 19 - docs/_sass/_gridism.scss | 125 -- docs/_sass/_mixins.scss | 38 - docs/_sass/_normalize.scss | 1 - docs/_sass/_pygments.scss | 78 -- docs/_sass/_style.scss | 1094 ----------------- docs/assets/css/screen.scss | 9 - docs/docs.sh | 61 - docs/github-io.md | 13 - 151 files changed, 10 insertions(+), 11834 deletions(-) delete mode 100644 docs/_config.yml delete mode 100644 docs/_data/artik.yml delete mode 100644 docs/_data/docs.yml delete mode 100644 docs/_data/openshift.yml delete mode 100644 docs/_data/tutorials.yml delete mode 100644 docs/_docs/artik-ide-plugin/artik-api-docs.md delete mode 100644 docs/_docs/artik-ide-plugin/artik-apisdk-management.md delete mode 100644 docs/_docs/artik-ide-plugin/artik-config.md delete mode 100644 docs/_docs/artik-ide-plugin/artik-docker.md delete mode 100644 docs/_docs/artik-ide-plugin/artik-download-ide.md delete mode 100644 docs/_docs/artik-ide-plugin/artik-network.md delete mode 100644 docs/_docs/artik-ide-plugin/artik-proxies.md delete mode 100644 docs/_docs/artik-ide-plugin/artik-release-notes.md delete mode 100644 docs/_docs/artik-ide-plugin/artik-start-mac.md delete mode 100644 docs/_docs/artik-ide-plugin/artik-start-windows.md delete mode 100644 docs/_docs/artik-ide-plugin/artik-tutorial-blink-led.md delete mode 100644 docs/_docs/artik-ide-plugin/artik-usb-connection-setup.md delete mode 100644 docs/_docs/artik-ide-plugin/artik-wireless-setup.md delete mode 100644 docs/_docs/chedir-portable-workspaces/chedir-chefiles.md delete mode 100644 docs/_docs/chedir-portable-workspaces/chedir-factories.md delete mode 100644 docs/_docs/chedir-portable-workspaces/chedir-getting-started.md delete mode 100644 docs/_docs/chedir-portable-workspaces/chedir-installation.md delete mode 100644 docs/_docs/chedir-portable-workspaces/chedir-project-setup.md delete mode 100644 docs/_docs/chedir-portable-workspaces/chedir-ssh.md delete mode 100644 docs/_docs/chedir-portable-workspaces/chedir-up-and-down.md delete mode 100644 docs/_docs/chedir-portable-workspaces/chedir-why.md delete mode 100644 docs/_docs/index.html delete mode 100644 docs/_docs/openshift-plugin/openshift-config.md delete mode 100644 docs/_docs/openshift-plugin/openshift-user-guide.md delete mode 100644 docs/_docs/setup/che-setup-bitnami.md delete mode 100644 docs/_docs/setup/che-setup-cli.md delete mode 100644 docs/_docs/setup/che-setup-configuration.md delete mode 100644 docs/_docs/setup/che-setup-docker.md delete mode 100644 docs/_docs/setup/che-setup-getting-started-saas-cloud.md delete mode 100644 docs/_docs/setup/che-setup-getting-started.md delete mode 100644 docs/_docs/setup/che-setup-glossary.md delete mode 100644 docs/_docs/setup/che-setup-intro.md delete mode 100644 docs/_docs/setup/che-setup-managing.md delete mode 100644 docs/_docs/tutorials/tutorial-android.md delete mode 100644 docs/_docs/tutorials/tutorial-che-and-appfog.md delete mode 100644 docs/_docs/tutorials/tutorial-che-in-che.md delete mode 100644 docs/_docs/tutorials/tutorial-cuba.md delete mode 100644 docs/_docs/tutorials/tutorial-ftpsftp.md delete mode 100644 docs/_docs/tutorials/tutorial-gae.md delete mode 100644 docs/_docs/tutorials/tutorial-gradle.md delete mode 100644 docs/_docs/tutorials/tutorial-java.md delete mode 100644 docs/_docs/tutorials/tutorial-laravel.md delete mode 100644 docs/_docs/tutorials/tutorial-maven.md delete mode 100644 docs/_docs/tutorials/tutorial-meteor.md delete mode 100644 docs/_docs/tutorials/tutorial-multi-machine.md delete mode 100644 docs/_docs/tutorials/tutorial-nodejs.md delete mode 100644 docs/_docs/tutorials/tutorial-php.md delete mode 100644 docs/_docs/tutorials/tutorial-platformio.md delete mode 100644 docs/_docs/tutorials/tutorial-rails.md delete mode 100644 docs/_docs/tutorials/tutorial-sourcegraph.md delete mode 100644 docs/_docs/tutorials/tutorial-spring-boot.md delete mode 100644 docs/_docs/tutorials/tutorial-subversion.md delete mode 100644 docs/_docs/tutorials/tutorial-swing.md delete mode 100644 docs/_docs/tutorials/tutorial-tomee.md delete mode 100644 docs/_docs/tutorials/tutorial-vaadin.md delete mode 100644 docs/_docs/tutorials/tutorial-wordpress.md delete mode 100644 docs/_docs/use-che-as-a-workspace-server/server-api-projects.md delete mode 100644 docs/_docs/use-che-as-a-workspace-server/server-build-run.md delete mode 100644 docs/_docs/use-che-as-a-workspace-server/server-create-workspaces.md delete mode 100644 docs/_docs/use-che-as-a-workspace-server/server-events.md delete mode 100644 docs/_docs/use-che-as-a-workspace-server/server-project-types.md delete mode 100644 docs/_docs/use-che-as-a-workspace-server/server-rest-api.md delete mode 100644 docs/_docs/use-che-as-a-workspace-server/server-stack.md delete mode 100644 docs/_docs/use-che-as-a-workspace-server/server-websocket-api.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-build.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-commands.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-debug.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-docker.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-editor-settings.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-electron.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-git-svn.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-import-a-project.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-intellisense.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-previews.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-projects.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-run.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-sharing.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-ssh.md delete mode 100644 docs/_docs/use-che-as-an-ide/ide-sync.md delete mode 100644 docs/_docs/workspace-administration/ws-admin-intro.md delete mode 100644 docs/_docs/workspace-administration/ws-agents.md delete mode 100644 docs/_docs/workspace-administration/ws-data-model-samples.md delete mode 100644 docs/_docs/workspace-administration/ws-data-model-stacks.md delete mode 100644 docs/_docs/workspace-administration/ws-machines.md delete mode 100644 docs/_docs/workspace-administration/ws-recipes.md delete mode 100644 docs/_docs/workspace-administration/ws-samples.md delete mode 100644 docs/_docs/workspace-administration/ws-stacks.md delete mode 100644 docs/_docs/workspace-administration/ws-volume-mounts.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-actions.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-assemblies.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-calling-workspace-apis.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-che-properties.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-code-editors.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-create-and-build-extensions.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-dependency-injection-basics.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-embed-htmljs.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-helloworld-extension.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-introduction.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-java-class-reference.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-native-access-to-the-workspace.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-parts.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-project-types.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-serverworkspace-access.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-setup-che-workspace.md delete mode 100644 docs/_docs/write-che-ide-plugins/plugins-themes.md delete mode 100644 docs/_includes/analytics.html delete mode 100644 docs/_includes/anchor_links.html delete mode 100644 docs/_includes/base.html delete mode 100644 docs/_includes/default.html delete mode 100644 docs/_includes/docs_contents.html delete mode 100644 docs/_includes/docs_contents_mobile.html delete mode 100644 docs/_includes/docs_option.html delete mode 100644 docs/_includes/docs_ul.html delete mode 100644 docs/_includes/error.html delete mode 100644 docs/_includes/footer.html delete mode 100644 docs/_includes/header-github-io.html delete mode 100644 docs/_includes/header.html delete mode 100644 docs/_includes/news.html delete mode 100644 docs/_includes/news_contents.html delete mode 100644 docs/_includes/news_contents_mobile.html delete mode 100644 docs/_includes/news_item.html delete mode 100644 docs/_includes/page.html delete mode 100644 docs/_includes/primary-nav-items.html delete mode 100644 docs/_includes/section_nav.html delete mode 100644 docs/_includes/top.html delete mode 100644 docs/_layouts/artik.html delete mode 100644 docs/_layouts/default.html delete mode 100644 docs/_layouts/docs.html delete mode 100644 docs/_layouts/error.html delete mode 100644 docs/_layouts/github-io.html delete mode 100644 docs/_layouts/news.html delete mode 100644 docs/_layouts/news_item.html delete mode 100644 docs/_layouts/openshift.html delete mode 100644 docs/_layouts/page.html delete mode 100644 docs/_layouts/tutorials.html delete mode 100644 docs/_sass/_font-awesome.scss delete mode 100644 docs/_sass/_gridism.scss delete mode 100644 docs/_sass/_mixins.scss delete mode 100644 docs/_sass/_normalize.scss delete mode 100644 docs/_sass/_pygments.scss delete mode 100644 docs/_sass/_style.scss delete mode 100644 docs/assets/css/screen.scss delete mode 100644 docs/docs.sh delete mode 100644 docs/github-io.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5ab776ffe86..b2f49145f7c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -30,3 +30,12 @@ Therefore: Contributing Improvements ------------------------- If you are interested in fixing issues and contributing directly to the code base, please the document [How to Contribute](https://github.com/eclipse/che/wiki/How-To-Contribute). + + +Dependency Repositories +------------------------- +Eclipse Che is dependent on the following external repositories to build: + +[https://github.com/codenvy/che-docs](https://github.com/codenvy/che-docs) + +Run `mvn clean install` for the repositories above to create required artifacts before building Che. diff --git a/docs/README.md b/docs/README.md index 2472f781969..ae9a7ca213b 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,2 +1 @@ -# Eclipse Che Docs -REPLACE ME WITH INSTRUCTIONS ABOUT HOW TO VIEW, EDIT, AND CONTRIBUTE TO CHE DOCS. +Docs are located in seperate repository [https://github.com/codenvy/che-docs](https://github.com/codenvy/che-docs). diff --git a/docs/_config.yml b/docs/_config.yml deleted file mode 100644 index e9c7efba68d..00000000000 --- a/docs/_config.yml +++ /dev/null @@ -1,110 +0,0 @@ -markdown: kramdown -highlighter: rouge - - -kramdown: - toc_levels: 1..6 - smart_quotes: lsquo,rsquo,ldquo,rdquo - input: GFM - -repository: https://github.com/codenvy/codenvy -#help_url: https://github.com/jekyll/jekyll-help - -timezone: America/Los_Angeles - -collections: - docs: - output: true - tutorials: - output: true - openshift: - output: true - artik: - output: true - -name: Eclipse Che Docs -description: Cloud workspaces for development teams -url: https://www.eclipse.org/che/ - -product_name: "CHE" -product_mini_name: "Che" -product_formal_name: "Eclipse Che" - -twitter: - username: eclipse_che - -logo: /img/logo-2x.png - -gems: - - jekyll-feed - - jekyll-redirect-from - - jekyll-sitemap - -exclude: - - /dev/ - - README.md - - .gitignore - - docs.sh - - assembly/* - - _site/* - - pom.xml - - - # The following are used to define markdown permalinks -defaults: - - - scope: - path: "_docs/write-che-ide-plugins" - values: - categories: [ "docs" , "plugins" ] - - - scope: - path: "_docs/workspace-administration" - values: - categories: [ "docs" , "workspace" ] - - - - scope: - path: "_docs/use-che-as-an-ide" - values: - categories: [ "docs" , "ide" ] - - - scope: - path: "_docs/use-che-as-a-workspace-server" - values: - categories: [ "docs" , "server" ] - - - scope: - path: "_docs/tutorials" - values: - categories: [ "tutorials" ] - - - scope: - path: "_docs/setup-alternatives" - values: - categories: [ "docs" , "setup-alternatives" ] - - - scope: - path: "_docs/setup" - values: - categories: [ "docs" , "setup" ] - - - scope: - path: "_docs/openshift-plugin" - values: - category: [ "openshift" ] - - - scope: - path: "_docs/chedir-portable-workspaces" - values: - categories: [ "docs" , "chedir" ] - - - scope: - path: "_docs/che-data-model" - values: - categories: [ "docs" , "data-model" ] - - - scope: - path: "_docs/artik-ide-plugin" - values: - categories: [ "artik" ] diff --git a/docs/_data/artik.yml b/docs/_data/artik.yml deleted file mode 100644 index f69ee9f54ec..00000000000 --- a/docs/_data/artik.yml +++ /dev/null @@ -1,15 +0,0 @@ -- title: ARTIK IDE - artik: - - artik-start-windows - - artik-start-mac - - artik-proxies - - artik-config - - artik-network - - artik-usb-connection-setup - - artik-docker - - artik-tutorial-blink-led - - artik-apisdk-management - - artik-api-docs - - artik-release-notes - - artik-wireless-setup - - artik-download-ide diff --git a/docs/_data/docs.yml b/docs/_data/docs.yml deleted file mode 100644 index 5a5edbc86e1..00000000000 --- a/docs/_data/docs.yml +++ /dev/null @@ -1,78 +0,0 @@ -- title: SETUP - docs: - - che-setup-intro - - che-setup-getting-started - - che-setup-getting-started-saas-cloud - - che-setup-bitnami - - che-setup-configuration - - che-setup-managing - - che-setup-cli - - che-setup-glossary - - che-setup-docker -- title: WORKSPACE ADMINISTRATION - docs: - - ws-admin-intro - - ws-stacks - - ws-recipes - - ws-samples - - ws-machines - - ws-volume-mounts - - ws-agents - - ws-data-model-stacks - - ws-data-model-samples -- title: USER GUIDE - docs: - - ide-projects - - ide-import-a-project - - ide-ssh - - ide-sync - - ide-editor-settings - - ide-intellisense - - ide-commands - - ide-git-svn - - ide-previews - - ide-build - - ide-run - - ide-sharing - - ide-debug - - ide-docker - - ide-electron -- title: CHEDIR - PORTABLE WORKSPACES - docs: - - chedir-getting-started - - chedir-why - - chedir-installation - - chedir-project-setup - - chedir-up-and-down - - chedir-chefiles - - chedir-ssh - - chedir-factories -- title: DEVELOPER GUIDE - REST API - docs: - - server-rest-api - - server-api-projects - - server-build-run - - server-create-workspaces - - server-events - - server-project-types - - server-stack - - server-websocket-api -- title: DEVELOPER GUIDE - IDE PLUGINS - docs: - - plugins-introduction - - plugins-setup-che-workspace - - plugins-create-and-build-extensions - - plugins-assemblies - - plugins-dependency-injection-basics - - plugins-code-editors - - plugins-project-types - - plugins-actions - - plugins-serverworkspace-access - - plugins-parts - - plugins-calling-workspace-apis - - plugins-java-class-reference - - plugins-che-properties - - plugins-native-access-to-the-workspace - - plugins-embed-htmljs - - plugins-helloworld-extension - - plugins-themes \ No newline at end of file diff --git a/docs/_data/openshift.yml b/docs/_data/openshift.yml deleted file mode 100644 index a4847dccf27..00000000000 --- a/docs/_data/openshift.yml +++ /dev/null @@ -1,4 +0,0 @@ -- title: OPENSHIFT PLUG-IN FOR ECLIPSE CHE - openshift: - - openshift-config - - openshift-user-guide diff --git a/docs/_data/tutorials.yml b/docs/_data/tutorials.yml deleted file mode 100644 index edf3dfe470e..00000000000 --- a/docs/_data/tutorials.yml +++ /dev/null @@ -1,25 +0,0 @@ -- title: User Tutorials - tutorials: - - tutorial-multi-machine - - tutorial-maven - - tutorial-gradle - - tutorial-java - - tutorial-swing - - tutorial-nodejs - - tutorial-meteor - - tutorial-wordpress - - tutorial-php - - tutorial-android - - tutorial-spring-boot - - tutorial-rails - - tutorial-laravel - - tutorial-tomee - - tutorial-che-in-che - - tutorial-gae - - tutorial-che-and-appfog - - tutorial-subversion - - tutorial-ftpsftp - - tutorial-cuba - - tutorial-sourcegraph - - tutorial-vaadin - - tutorial-platformio diff --git a/docs/_docs/artik-ide-plugin/artik-api-docs.md b/docs/_docs/artik-ide-plugin/artik-api-docs.md deleted file mode 100644 index 4a9dc2274e2..00000000000 --- a/docs/_docs/artik-ide-plugin/artik-api-docs.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: API Docs -excerpt: "" -layout: artik -permalink: /:categories/api-docs/ ---- -{% include base.html %} - -Artik IDE provides API docs for a particular SDK version installed in a developer workspace. Included in these documents are many useful code examples which are provide in ARTIK sample project **Workspace > Create Project > artik-samples** . - - -Docs are available in the right side tab or at **Artik > Show API Documentation** in the menu bar. -![artikapi.jpg]({{ base }}/assets/imgs/artikapi.jpg) - -# Context Sensitive Help -Select any Artik specific keyword (function name, object etc) and press **Ctrl + Q**. A new tab will be opened (you may need to allow popups from Artik IDE in your browser) to display docs for a selected keyword. If nothing is found in a selected keyword, an error message will pop up. - - -![artikctrlq.jpg]({{ base }}/assets/imgs/artikctrlq.jpg) diff --git a/docs/_docs/artik-ide-plugin/artik-apisdk-management.md b/docs/_docs/artik-ide-plugin/artik-apisdk-management.md deleted file mode 100644 index 0903cf43fb1..00000000000 --- a/docs/_docs/artik-ide-plugin/artik-apisdk-management.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: API/SDK -excerpt: "" -layout: artik -permalink: /:categories/apisdk-management/ ---- -{% include base.html %} -Artik IDE provides a mechanism to manage (install, upgrade and downgrade) Artik SDK and dependency libs both in a developer workspace and on the device at `Artik > Manage SDK/APIs...`. - -Artik plugin will check currently installed SDK versions on the device(s) and in a developer workspace. Available versions are fetched from Artik yum repository. diff --git a/docs/_docs/artik-ide-plugin/artik-config.md b/docs/_docs/artik-ide-plugin/artik-config.md deleted file mode 100644 index c11945cf085..00000000000 --- a/docs/_docs/artik-ide-plugin/artik-config.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Setup: Configuration -excerpt: "Advanced configuration for the ARTIK IDE." -layout: artik -permalink: /:categories/config/ ---- -{% include base.html %} diff --git a/docs/_docs/artik-ide-plugin/artik-docker.md b/docs/_docs/artik-ide-plugin/artik-docker.md deleted file mode 100644 index 4162a4da633..00000000000 --- a/docs/_docs/artik-ide-plugin/artik-docker.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Setup: Docker -excerpt: "Configuring Docker for the ARTIK IDE." -layout: artik -permalink: /:categories/docker/ ---- -{% include base.html %} -ARTIK IDE workspaces are based on a Docker image. You can either pull that image from a public registry, like Docker Hub, or a private registry which is managed by yourself. Images in a registry can be publicly visible or private, which require user credentials to access. You can also set up a private registry to act as a mirror to Docker Hub. And, if you are running the ARTIK IDE behind a proxy, you can configure the Docker daemon registry to operate behind a proxy. diff --git a/docs/_docs/artik-ide-plugin/artik-download-ide.md b/docs/_docs/artik-ide-plugin/artik-download-ide.md deleted file mode 100644 index e8b1f223752..00000000000 --- a/docs/_docs/artik-ide-plugin/artik-download-ide.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Download -excerpt: "Downloading" -layout: artik -permalink: /:categories/download-ide/ ---- -{% include base.html %} -The easiest way to get started with ARTIK is by following the instructions in our [Getting Started](../../docs/artik/) page. - - -The instructions below are for experienced developers who wish to install Che as a native server. -# Packages -Packages extract the ARTIK IDE into a working directory. You must have Java 1.8 installed. Windows and MacOS also require Docker Toolbox to be separately installed, which itself installs Git Bash, Virtual Box, and Docker. - -**ZIP Package for Windows, Mac, and Linux** -Installs Che in any directory. -[❯ Download latest release (142 MB)]() `TBD LINK` -[❯ Download nightly (142 MB)]() `TBD LINK` - -**TGZ Package for Windows, Mac, and Linux** -Installs Che in any directory. -[❯ Download latest release (137 MB)]() `TBD LINK` -[❯ Download nightly (137 MB)]() `TBD LINK` - -Need help getting the ARTIK IDE to run? Please check the oodles of Eclipse Che installation and usage docs. -# Prerequisities -The ARTIK IDE has the same prerequisites as Eclipse Che. The [prerequisites](../../docs/usage/) page in our docs itemizes the list of dependencies and how they are used. - -# Build Assembly from Source -You will need Maven, Java, and Git to build the ARTIK IDE from source. [Our GitHub repository has build and contribution instructions](https://github.com/codenvy/artik-ide). -# Older Releases diff --git a/docs/_docs/artik-ide-plugin/artik-network.md b/docs/_docs/artik-ide-plugin/artik-network.md deleted file mode 100644 index 780c7813c82..00000000000 --- a/docs/_docs/artik-ide-plugin/artik-network.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Setup: Networking -excerpt: "Setting up networking for the ARTIK IDE." -layout: artik -permalink: /:categories/network/ ---- -{% include base.html %} -The ARTIK IDE makes connections between three entities: the browser, the Che server (which runs the ARTIK IDE) running in a Docker container, and a workspace running in a Docker container. - -If you distribute these components onto different nodes, hosts or IP addresses, then you may need to add additional configuration parameters to bridge different networks. - -Also, since the ARTIK server and your ARTIK workspaces are within containers governed by a Docker daemon, you also need to ensure that these components have good bridges to communicate with the daemon. - -Generally, if your browser, ARTIK server and ARTIK workspaces are all on the same node, then localhost configuration will always work. diff --git a/docs/_docs/artik-ide-plugin/artik-proxies.md b/docs/_docs/artik-ide-plugin/artik-proxies.md deleted file mode 100644 index b8c4783d129..00000000000 --- a/docs/_docs/artik-ide-plugin/artik-proxies.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Setup: Proxies -excerpt: "Setting up the ARTIK IDE behind a proxy." -layout: artik -permalink: /:categories/proxies/ ---- -{% include base.html %} -Your users may need their workspaces to operate over a proxy to the Internet. The ARTIK IDE has three dependencies to the Internet: - -1. Docker, in order to download Docker images from DockerHub. -2. Importers, in order to clone sample projects or source code at an external repository to mount into a workspace. -3. Workspaces created by users, which have their own internal operating system. Users that want to reach the Internet from within their workspace, such as for `maven` or `npm`, also need a proxy configuration. diff --git a/docs/_docs/artik-ide-plugin/artik-release-notes.md b/docs/_docs/artik-ide-plugin/artik-release-notes.md deleted file mode 100644 index b186ff8bd0b..00000000000 --- a/docs/_docs/artik-ide-plugin/artik-release-notes.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Release Notes -excerpt: "Notes on features and bugs fixed in ARTIK IDE releases." -layout: artik -permalink: /:categories/release-notes/ ---- -{% include base.html %} -# ARTIK IDE 1.1.0 -## Bugs Fixed -* Deleting a device from the list of Artik devices does not delete it from consoles panel -* Consoles panel: Firefox bugfixes -* [Delete ARTIK device on "Manage Artik Devices" page without disconnect](https://github.com/codenvy/artik-ide/issues/106) -* [The status (CPU, MEM, DISK) of ARTIK board can not show, after open the terminal](https://github.com/codenvy/artik-ide/issues/107) -* [Cannot open the terminal of ARTIK board, after connect multiple boards](https://github.com/codenvy/artik-ide/issues/108) - - -# ARTIK IDE 1.0 -### Features Added -* Show online documentation in the ARTIK IDE -* Added development profile for ARTIK device that installs appropriate dev libraries and readies device for application creation -* Added production profile for Artik devices which removes all dev-specific libraries and settings -* Resource monitor for Artik devices showing CPU, memory and disk activity -* Commands can be targeted to any device and pre-targeted to an expected device -* Use of rsync to replicate project sources between device and IDE workspace automatically -* Context sensitive help for Artik SDK keywords -* Device logging: added user customizable command to tail relevant logs -* Split editor views both horizontally and vertically -* Split terminal views both horizontally and vertically -* Packaging of ARTIK dockerfiles for workspace creation -* Simplified debugger setup (consolidation of menus) -* ARTIK API integration: SDK/API management wizard -* ARTIK API integration: Show current SDK/API versions -* ARTIK API integration: New SDK/API version detection -* ARTIK API integration: Change SDK/API version in workspace and device - -# ARTIK IDE Beta -### Features Added -* IDE features based on Eclipse Che -* Add devices panel with shortcut menu button -* Remote shell access to devices and workspace -* Commands for building a deploying binaries -* Push to device: scp selected files/folders to the selected target board -* Ability to trace logs -* Discovery of ARTIK devices plugged into USB via ADB bridge -* Code formatting and coloring for ARTIK supported languages -* Access to ARTIK example applications from inside the ARTIK IDE -* Creation of default ARTIK and Android [Stacks](../../docs/stacks) to the ARTIK IDE diff --git a/docs/_docs/artik-ide-plugin/artik-start-mac.md b/docs/_docs/artik-ide-plugin/artik-start-mac.md deleted file mode 100644 index b0b1fb8579e..00000000000 --- a/docs/_docs/artik-ide-plugin/artik-start-mac.md +++ /dev/null @@ -1,161 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Getting Started - Mac & Linux -excerpt: "" -layout: artik -permalink: /:categories/start-mac/ ---- -{% include base.html %} -The Samsung ARTIK IDE is based upon Eclipse Che and runs on Windows, Mac or Linux. - -Mac and Linux users follow the instructions below. -Windows users use the instructions on [this page](../../docs/artik/). - -# How to Get Help -**Support:** If the unthinkable happens, or you have a question, you can post [issues on our GitHub page](https://github.com/eclipse/che/issues). Please follow the [guidelines on issue reporting](https://github.com/eclipse/che/blob/master/CONTRIBUTING.md). - -**Documentation:** We put a lot of effort into our docs. Please add suggestions on areas for improvement. -# 0. Pre-Reqs -Before installing the ARTIK IDE you will need: -1. Docker 1.8+ - - Docker for [Mac](https://docs.docker.com/engine/installation/mac/). - - Docker for [Linux](https://docs.docker.com/engine/installation/). -2. A bash shell -3. A Chrome or FireFox browser. - -```shell -# Verify Docker is properly installed -# Should print "Hello from Docker!" otherwise check Docker install docs -docker run hello-world - -# Should open a bash shell -bash -``` -If using Docker for Mac, add the following to your `~/.bash_profile`. -``` - -# 1. Get ARTIK IDE CLI -On Linux / Mac, from in a bash shell execute: -```text -sudo curl -sL https://raw.githubusercontent.com/codenvy/artik-ide/master/artik-ide.sh > /usr/local/bin/artik-ide -sudo chmod +x /usr/local/bin/artik-ide\ -``` - -#### Installing Behind a Proxy -If you are behind a proxy, you need to [configure your proxy settings](../../docs/che-config-proxies) for Docker and the ARTIK IDE. - -# 2. Start ARTIK IDE - -#### Locahost on Mac OS -On Mac OS the ARTIK IDE will be available at http://localhost:8080 - - -```shell -# Change where workspaces are saved. Default = /home/user/che -# export CHE_DATA_FOLDER=/home/user/reginald - -# If ARTIK will be accessed from other machines define your host IP -# export CHE_HOST_IP= - -# Start ARTIK IDE -artik-ide start -INFO: ARTIK-IDE: Found image codenvy/che-launcher:nightly -INFO: ARTIK-IDE: Starting launcher -INFO: ARTIK-IDE: Already have image codenvy/artikide:nightly -INFO: ARTIK-IDE: Starting container... -INFO: ARTIK-IDE: Server logs at "docker logs -f artik-ide" -INFO: ARTIK-IDE: Server booting... -INFO: ARTIK-IDE: Booted and reachable -INFO: ARTIK-IDE: http://192.168.99.100:8080 -# Copy the URL shown in the terminal to your browser to open the dashboard -# Mac OS users will open the IDE at http://localhost:8080 - -# Stop ARTIK IDE -artik-ide stop - -# Update ARTIK IDE to the newest version -export CHE_VERSION=latest -artik-ide update - -# List all CLI commands -artik-ide help -``` - -#### Advanced Configuration -There are many aspects of ARTIK IDE like port and hostname that can be configured by [setting Eclipse Che properties](../../docs/usage-docker#environment-variables). - - -# 3. Create Workspaces and Projects -The ARTIK IDE provides a step-by-step wizard for creating your first workspace. It provides stacks for ARTIK and Android, as well as many other languages through the "Stack Library." Stacks will populate the workspace with a runtime, SDK, and libraries needed for building new projects that will run on an ARTIK board. - -A workspace can have one or more projects. Each project can have a different type that supports different kinds of programming languages and build frameworks. When you create your first workspace, you can provide the project from a Git repository or using one of the included templates. -![createwsandproject.jpg]({{ base }}/assets/imgs/createwsandproject.jpg) -Choose the ARTIK stack and then select from one of the many sample projects. [Tutorial: Artik Blink LED](../../docs/tutorial-artik-blink-led) is a good starter tutorial that uses the Ready-to-run project template `artik-blink-led`. - -# 4. Setup an ARTIK Device -Review Samsung ARTIK getting started docs at [https://developer.artik.io/documentation/getting-started-beta/powering-up.html](https://developer.artik.io/documentation/getting-started-beta/powering-up.html) and [https://developer.artik.io/documentation/getting-started-beta/communicating-pc.html](https://developer.artik.io/documentation/getting-started-beta/communicating-pc.html). This will help understand how to power up the ARTIK device(connect power and press SW3 switch) and how to setup communication with the ARTIK device. - -# 5. Discover ARTIK Device IP Address -The quickest way to get started is to connect your ARTIK device to the computer running the ARTIK IDE with a male USB to male USB cable: [quick connection over USB discovery](../../docs/artik-usb-connection-setup). However, this cable doesn't ship with the ARTIK device and connecting over the network is often required in the long-term. - -Connect your ARTIK board to your network router/switch via network cable. The ARTIK device will then obtain an IP address automatically using DHCP. To discover your ARTIK IP address log into your router and search the table of clients for the name "localhost". Also, you can discover your artik board IP address with the following utility. -```shell -#Determine your current computers IP to search network for ARTIK Board. -export HOST_IP=$(docker run --rm --net host alpine sh -c "ip a show eth1" | \ - grep 'inet ' | cut -d/ -f1 | awk '{ print $2}') - -#Quick search for ARTIK device via open 22 port -docker run -ti --rm artik-tools jdrummond/artik-tools -q -i %HOST_IP% -t 5 - -#When above results in multiple ip addresses -docker run -ti --rm artik-tools jdrummond/artik-tools -i %HOST_IP% -t 20 - -#SSH in ARTIK device using ip address from above to test ip address validity. -#ARTIK device default username/password root/root. -ssh root@ -``` - -```shell -#Determine your current computers IP to search network for ARTIK Board. -for /f "skip=1 tokens=2 delims=: " %f in ('nslookup %COMPUTERNAME% ^| find /i "Address"') do set HOST_IP=%f - -#Quick search for ARTIK device via open 22 port -docker run -i --rm -t artik-tools jdrummond/artik-tools -q -i %HOST_IP% -t 5 - -#When above results in multiple ip addresses -docker run -i --rm -t artik-tools jdrummond/artik-tools -i %HOST_IP% -t 20 - -#SSH in ARTIK device using ip address from above to test ip address validity. -#ARTIK device default username/password root/root. -bash ->ssh root@ -``` -**Note: When the ARTIK device is powered up, it will request a new ip address each time. Be sure to determine the new ipaddress each time or give your ARTIK device a static ip address.** -# 6. Connect ARTIK Device with ARTIK IDE -Use the ARTIK device manager in a workspace to connect an ARTIK device to the ARTIK IDE. - -1. Click ARTIK icon on the toolbar in workspace. -2. Name your device, provide ARTIK device [IP address](../../docs/artik#5-discover-artik-device-ip-address) and port(default 22) and username/password(default root/root). - -3. Specify replication path on the device. This is the directory where project files will be backed up on the device. It can be both existing or a non existing directory (in the latter case it will be created). Project source files (including binaries) are automatically `scp`'ed into all connected targets when changes in a workspace file system are caught. It means that when a binary is rebuilt, it's readily available on the device in about a 2-3 seconds. -4. `Save` then `Connect`. -5. Once connected, ARTIK device tree will be created in processes area. Selecting the terminal icon will give access to the terminal console inside of ARTIK device. Also, the target environment will automatically change to ARTIK. This is important to note as all workspace commands will be ran inside the ARTIK device. Usually, building/compiling code is done inside workspace by setting target to `default` and executing/running commands are done inside the ARTIK device by setting target to `artik_device_<#>`. -![artikmanager.jpg]({{ base }}/assets/imgs/artikmanager.jpg) - -![artikmanageradddevice.jpg]({{ base }}/assets/imgs/artikmanageradddevice.jpg) - -# 7. Build, Run and Debug -See: [Getting Started - Windows](../../docs/artik#8-build) - -# 9. Production and Development Profiles -Your Artik device needs certain software to make it possible for Artik IDE to debug apps, sync project files, make use of C/C++ and Node SDKs. - -Turning on a development profile will install the minimum software package that includes node.js, rsync and a gdbserver. - -A production profile removes this software from the system. - -Profiles are available at **Artik > Profiles** or by right clicking the device in machines panel in the bottom. -# 10. Troubleshooting -If you experience problems, please file an issue on the [Eclipse Che GitHub page](https://github.com/eclipse/che/issues) where Che and ARTIK engineers can help you. -# 11. Contribute to the ARTIK IDE -* **Build From Source**: We love that idea. Che is a multi-module project, so you can build all of it, or just some of it. Start in the /assembly/assembly-main/ repository for the fastest build. We maintain build instructions on the [ARTIK IDE GitHub repository](https://github.com/codenvy/artik-ide). diff --git a/docs/_docs/artik-ide-plugin/artik-start-windows.md b/docs/_docs/artik-ide-plugin/artik-start-windows.md deleted file mode 100644 index 621d5437e4c..00000000000 --- a/docs/_docs/artik-ide-plugin/artik-start-windows.md +++ /dev/null @@ -1,222 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Getting Started - Windows -excerpt: "" -layout: artik -permalink: /:categories/start-windows/ ---- -{% include base.html %} -The Samsung ARTIK IDE is based upon Eclipse Che and runs on Windows, Mac or Linux. - -**Windows** users follow the instructions below. - -**Mac and Linux** users [use this page](../../docs/artik-start-mac/). - -# How to Get Help -**Support:** If the unthinkable happens, or you have a question, you can post [issues on our GitHub page](https://github.com/eclipse/che/issues). Please follow the [guidelines on issue reporting](https://github.com/eclipse/che/blob/master/CONTRIBUTING.md). - -**Documentation:** We put a lot of effort into our docs. Please add suggestions on areas for improvement. -# 0. Pre-Reqs -Before installing the ARTIK IDE you will need: -- **Windows 10** - 1. Install [Docker for Windows](https://docs.docker.com/engine/installation/windows/) - ARTIK IDE requires Docker 1.8+. - 2. Enable [bash in Windows](http://www.pcworld.com/article/3106463/windows/how-to-get-bash-on-windows-10-with-the-anniversary-update.html) or install [git for Windows](https://git-scm.com/download/win) to get a bash shell. - 3. Use a Chrome or FireFox browser. -- **Windows 7 or 8** - 1. Install [Docker Toolbox](https://docs.docker.com/toolbox/toolbox_install_windows/). - 2. Install [git for Windows](https://git-scm.com/download/win) to get a bash shell. - 3. Use a Chrome or FireFox browser. - -# 1. Verify Docker -Add Git Bash to the system path by setting `PATH=;%PATH%`: -```shell -set PATH=C:\Program Files\Git\bin\;%PATH%\ -``` -Verify Docker by running the Docker hello world example. -```shell -docker run hello-world\ -``` -You should see Docker output and a hello world message. - -Now, verify that bash works: -```shell -bash\ -``` -You should see a bash prompt. Keep the bash session open for the next step. -# 2. Get ARTIK IDE CLI -You will need to set the directory where you would like to keep ARTIK IDE executables. In the example below we use `/c/Users/$USERNAME/artik-ide` but this can be changed. -#### Directories for Docker -Docker and bash are case sensitive and require forward slashes without colons for directory and path names. Errors can occur if directories have spaces in them. - -From the bash prompt: -```shell -mkdir /c/Users/$USERNAME/artik-ide -cd /c/Users/$USERNAME/artik-ide\ -``` -Now, download the `artik-ide.bat` and `artik-ide.sh` scripts: -```shell -curl -sL https://raw.githubusercontent.com/codenvy/artik-ide/master/artik-ide.bat > artik-ide.bat - -curl -sL https://raw.githubusercontent.com/codenvy/artik-ide/master/artik-ide.sh > artik-ide.sh\ -``` -Finally, set the location for workspace storage in the ARTIK IDE. If using boot2docker, set the ARTIK IDE workspace storage to a subdirectory of `%userprofile%`. - -If running Docker for Windows on Windows 10 Professional or Enterprise, you can set it to any directory. -```shell -mkdir %userprofile%\artik-ide\data\ -``` -Once downloaded you can exit bash: -```shell -exit\ -``` - -#### Installing Behind a Proxy -If you are behind a proxy, you need to [configure your proxy settings](../../docs/che-config-proxies/) for Docker and the ARTIK IDE. - - - -# 3. Start ARTIK IDE -From the directory where you downloaded the `artik-ide.bat` set the `CHE_DATA_FOLDER` environment variable. This is persisted for each session. To persist it across sessions set it as a [system variable](http://www.computerhope.com/issues/ch000549.htm). -```shell -set CHE_DATA_FOLDER=/c/Users/%USERNAME%/artik-ide/data -set PATH=;%PATH%\ -``` -If you have set system variables for the above you can start here for future sessions. - -Start the ARTIK-IDE: -```shell -artik-ide start - -INFO: ARTIK-IDE: Found image eclipse/che-launcher -INFO: ARTIK-IDE: Starting launcher -INFO: ARTIK-IDE: Already have image codenvy/artikide -INFO: ARTIK-IDE: Starting container... -INFO: ARTIK-IDE: Server logs at "docker logs -f artik-ide" -INFO: ARTIK-IDE: Server booting... -INFO: ARTIK-IDE: Booted and reachable -INFO: ARTIK-IDE: http://192.168.99.100:8080 -``` -Copy the URL shown in the terminal to your browser to open the dashboard. - -To stop the ARTIK IDE: -```shell -artik-ide stop\ -``` -To update ARTIK IDE to the newest version you can set the `CHE_VERSION` to `latest`. Otherwise you can select a tag from the released versions at [Dockerhub](https://hub.docker.com/r/codenvy/artikide/tags/) -```shell -set CHE_VERSION=latest -artik-ide update\ -``` -See all the CLI commands: -```shell -artik-ide help\ -``` - -#### Advanced Configuration -There are many aspects of ARTIK IDE like port and hostname that can be configured by [setting Eclipse Che properties](../../docs/usage-docker#environment-variables). - - - -# 4. Create Workspaces and Projects -The ARTIK IDE provides a step-by-step wizard for creating your first workspace. It provides stacks for ARTIK and Android, as well as many other languages through the "Stack Library." Stacks will populate the workspace with a runtime, SDK, and libraries needed for building new projects that will run on an ARTIK board. - -A workspace can have one or more projects. Each project can have a different type that supports different kinds of programming languages and build frameworks. When you create your first workspace, you can provide the project from a Git repository or using one of the included templates. -![createwsandproject.jpg]({{ base }}/assets/imgs/createwsandproject.jpg) -Choose the ARTIK stack and then select from one of the many sample projects. [Tutorial: Artik Blink LED](../../docs/artik-tutorial-blink-led/) is a good starter tutorial that uses the Ready-to-run project template `artik-blink-led`. - -# 5. Setup an ARTIK Device -Review Samsung ARTIK getting started docs at [https://developer.artik.io/documentation/getting-started-beta/powering-up.html](https://developer.artik.io/documentation/getting-started-beta/powering-up.html) and [https://developer.artik.io/documentation/getting-started-beta/communicating-pc.html](https://developer.artik.io/documentation/getting-started-beta/communicating-pc.html). This will help understand how to power up the ARTIK device(connect power and press SW3 switch) and how to setup communication with the ARTIK device. - -# 6. Discover ARTIK Device IP Address -The quickest way to get started is to connect your ARTIK device to the computer running the ARTIK IDE with a male USB to male USB cable: [quick connection over USB discovery](../../docs/artik-usb-connection-setup/).However, this cable doesn't ship with the ARTIK device and connecting over the network is often required in the long-term. - -Connect your ARTIK board to your network router/switch via network cable. The ARTIK device will then obtain an IP address automatically using DHCP. To discover your ARTIK IP address log into your router and search the table of clients for the name "localhost". Also, you can discover your artik board IP address with the following utility. -```shell -#Determine your current computers IP to search network for ARTIK Board. -export HOST_IP=$(docker run --rm --net host alpine sh -c "ip a show eth1" | \ - grep 'inet ' | cut -d/ -f1 | awk '{ print $2}') - -#Quick search for ARTIK device via open 22 port -docker run -ti --rm artik-tools jdrummond/artik-tools -q -i %HOST_IP% -t 5 - -#When above results in multiple ip addresses -docker run -ti --rm artik-tools jdrummond/artik-tools -i %HOST_IP% -t 20 - -#SSH in ARTIK device using ip address from above to test ip address validity. -#ARTIK device default username/password root/root. -ssh root@ -``` - -```shell -#Determine your current computers IP to search network for ARTIK Board. -for /f "skip=1 tokens=2 delims=: " %f in ('nslookup %COMPUTERNAME% ^| find /i "Address"') do set HOST_IP=%f - -#Quick search for ARTIK device via open 22 port -docker run -i --rm -t artik-tools jdrummond/artik-tools -q -i %HOST_IP% -t 5 - -#When above results in multiple ip addresses -docker run -i --rm -t artik-tools jdrummond/artik-tools -i %HOST_IP% -t 20 - -#SSH in ARTIK device using ip address from above to test ip address validity. -#ARTIK device default username/password root/root. -```bash ->ssh root@ -``` -**Note: When the ARTIK device is powered up, it will request a new ip address each time. Be sure to determine the new ipaddress each time or give your ARTIK device a static ip address.** -# 7. Connect ARTIK Device with ARTIK IDE -Use the ARTIK device manager in a workspace to connect an ARTIK device to the ARTIK IDE. - -1. Click ARTIK icon on the toolbar in workspace. -2. Name your device, provide ARTIK device [IP address](#5-discover-artik-device-ip-address) and port(default 22) and username/password(default root/root). -3. Specify replication path on the device. This is the directory where project files will be backed up on the device. It can be both existing or a non existing directory (in the latter case it will be created). Project source files (including binaries) are automatically `scp`'ed into all connected targets when changes in a workspace file system are caught. It means that when a binary is rebuilt, it's readily available on the device in about a 2-3 seconds. -4. `Save` then `Connect`. -5. Once connected, ARTIK device tree will be created in processes area. Selecting the terminal icon will give access to the terminal console inside of ARTIK device. Also, the target environment will automatically change to ARTIK. This is important to note as all workspace commands will be ran inside the ARTIK device. Usually, building/compiling code is done inside workspace by setting target to `default` and executing/running commands are done inside the ARTIK device by setting target to `artik_device_<#>`. -![artikmanager.jpg]({{ base }}/assets/imgs/artikmanager.jpg) - -![artikmanageradddevice.jpg]({{ base }}/assets/imgs/artikmanageradddevice.jpg) - -![artikIDEafterconnection.jpg]({{ base }}/assets/imgs/artikIDEafterconnection.jpg) - -# 8. Build - -#### Building in the IDE -We recommend only building in the IDE workspace, not on the device itself because this is simpler and the IDE is smart enough to cross-compile the binary and push it to the device so it can be instantly run there. - -1. Select source file in the project explorer, click **Compile**. -![compile.png]({{ base }}/assets/imgs/compile.png) -Once built the binaries are automatically synced to the device and ready to run or debug and will show up in project explorer. - -#### Compilation Options -The default compilation command looks like this:`$CC -lartik-sdk-base $(for i in $(ls $CPATH)\ndo artik_sdk=-I$CPATH/$i\necho $artik_sdk\ndone) -lpthread -g` It is possible to change this command at `Project` > `Compilation Options`. This command is saved in project attributes and can be customized for each project. A user can also define the output binary name, which is **a.out** by default. - - -#### Project Replication -The project files (including both source and binaries) are automatically synced into the `project replication folder` on the device. You can set the project replication folder when adding or editing a device in the Device Manager dialog box (press the ARTIK IDE button on the menu bar). Read more about [connecting devices](#6-connect-artik-device-with-artik-ide). - - -# 9. Deploy, Run and Debug -**Run** -To run your application. select the project you want to run (it can be a source file as well) and press **Run** button. Note that you should first compile the project. The binary is run on the device, while the output is streamed to consoles panel in the IDE. - -**Debug** -Debugging requires `gdbserver` to be installed on the device. Older devices may not have this. When you connect a new device, the IDE will check if gdbserver is installed. If it's not, there will be a prompt suggesting that dev mode is to be turned on (which installs required software). - -To debug your application, choose the project (it can be source file as well), and click Debug (there will be dropdown with the list of connected devices). - -When debug is initiated, gdbserver is started on the device, on port 1234, and the IDE debugger automatically connects to it. -![debug_.png]({{ base }}/assets/imgs/debug_.png) -**Deploy (optional)** -Because all files in the project are auto-synced to the device it's not necessary to deploy anything to the device. However, if you want to push files to specific locations on the device (not the project replication folder) you can right-click on the artifact and choose `Push to Device` then `Choose Target...`. - -# 10. Production and Development Profiles -Your Artik device needs certain software to make it possible for Artik IDE to debug apps, sync project files, make use of C/C++ and Node SDKs. - -Turning on a development profile will install the minimum software package that includes node.js, rsync and a gdbserver. - -A production profile removes this software from the system. - -Profiles are available at **Artik > Profiles** or by right clicking the device in machines panel in the bottom. -# 11. Troubleshooting -If you experience problems, please file an issue on the [Eclipse Che GitHub page](https://github.com/eclipse/che/issues) where Che and ARTIK engineers can help you. -# 12. Contribute to the ARTIK IDE -* **Build From Source**: We love that idea. Che is a multi-module project, so you can build all of it, or just some of it. Start in the /assembly/assembly-main/ repository for the fastest build. We maintain build instructions on the [ARTIK IDE GitHub repository](https://github.com/codenvy/artik-ide). diff --git a/docs/_docs/artik-ide-plugin/artik-tutorial-blink-led.md b/docs/_docs/artik-ide-plugin/artik-tutorial-blink-led.md deleted file mode 100644 index e9f92a98178..00000000000 --- a/docs/_docs/artik-ide-plugin/artik-tutorial-blink-led.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Tutorial: Blink LED -excerpt: "" -layout: artik -permalink: /:categories/tutorial-blink-led/ ---- -{% include base.html %} -The ARTIK device and many other other embedded device have their own equivalents to the standard printed "Hello World!" program. To show that a device can interact with digital devices in the physical world a device blinks an LED to say "Hello". - -This tutorial assumes that the user has already gone thru the ARTIK [Getting Started](../../docs/artik/) documentation. - - -Open the ARTIK IDE in your web browser after issuing `artik-ide start`. Select `Dashboard` from the menu on the left. The will bring up the workspace and project creation interface to the right. Select `New from blank, template, or sample project`, select `Ready-to-go Stacks`, select `Artik`, name the workspace `artik`(could pick anything), change the ram to 2 GB, select the `Ready-to-run project samples` with our tutorial project `artik-blink-led`, and finally select the `Create` button either at the top right or located at the bottom. - -![artik-blink-led-1.jpg]({{ base }}/assets/imgs/artik-blink-led-1.jpg) -ARTIK IDE will then start creating the workspace. -![artik-blink-led-2.jpg]({{ base }}/assets/imgs/artik-blink-led-2.jpg) - -The ARTIK workspace once started will look like the following and bring up the `Manage Artik Devices` window. You will need to enter your ARTIK board ipaddress. The [Getting Started](../../docs/artik/#5-discover-artik-device-ip-address) page has information on how to get your ARTIK device ipaddress. A quick way though is to use the following docker CLI `docker run jdrummond/artik-tools -q -t 5 -i `. If more than one ipaddress is found, remove `-q` and try again. If a ipaddress is not found, make sure your ARTIK device is on with 3 leds on next to ANT3, connected to a network via wired/wireless and make sure you used is on the same network as your ARTIK device. -![artik-blink-led-3.jpg]({{ base }}/assets/imgs/artik-blink-led-3.jpg) - -![artik-blink-led-4.jpg]({{ base }}/assets/imgs/artik-blink-led-4.jpg) -Close the `Manage Artik Devices` window once the connection has been made. - -Click the drop down `CMD` menu located to the left of the blue play button. Select `artik-blink-led: build` from the drop down menu. Click the drop down menu `Targets` just to the left and select the `default` target. Hit the blue play button to run the `artik-blink-led: build` command. A tab will appear in the `Processes` area at the bottom. There will be no output from this command but don't worry it did create the assembly/binary file that can be used on the ARTIK device. -![artik-blink-led-5.jpg]({{ base }}/assets/imgs/artik-blink-led-5.jpg) - -![artik-blink-led-6.jpg]({{ base }}/assets/imgs/artik-blink-led-6.jpg) -The build creates a file called `a.out` in the projects root directory. In order to see the new file click the `artik-blink-led` root directory in the `Project Explorer` on the left then click the `refresh` button at the top right. Once this is done you will be able to see the `a.out` file. Right click on the `a.out` file and select from the drop down menu `Push To Device > artik_device_1`. A green popup should come up indicated the success of the push and the location of the `a.out` on the ARTIK device which by default is `/root`. -![artik-blink-led-7.jpg]({{ base }}/assets/imgs/artik-blink-led-7.jpg) - -![artik-blink-led-8.jpg]({{ base }}/assets/imgs/artik-blink-led-8.jpg) -Let's check to make sure our ARTIK device has our new `a.out` assembly file. Click the `terminal` button command in the `Processes` area next to the ARTIK target. Once open issue command `ls /root` on the ARTIK device terminal. You should be able to see the `a.out` file listed in the ARTIK device `/root` folder. -![artik-blink-led-9.jpg]({{ base }}/assets/imgs/artik-blink-led-9.jpg) -Now lets run `a.out` assembly on the ARTIK device. Select `Edit Commands ...` from the drop down `CMD` menu. Hit the `+` button next to `CUSTOM` to create a new command. Name the command `artik-blink-led: run` and enter `/root/a.out` for the command line. Hit the `save` button of the bottom right then close window. Next click the target window and select the target `artik_device_1`. This will make our new command `artik-blink-led: run` execute on the ARTIK device NOT in the workspace. -![artik-blink-led-11.jpg]({{ base }}/assets/imgs/artik-blink-led-11.jpg) - -![artik-blink-led-12.jpg]({{ base }}/assets/imgs/artik-blink-led-12.jpg) -Place an LED into between pin 13 and `GND`(newer ARTIK device models) or `Vref`(older ARTIK device models) depending on your model of ARTIK board. Refer to [Blink an LED](https://developer.artik.io/documentation/tutorials/blink-an-led.html) tutorial on ARTIK's documentation page for additional information. The image below shows the LED plugged into the newer model using the pin 13 and `GND`. -![artik-blink-led-13.jpg]({{ base }}/assets/imgs/artik-blink-led-13.jpg) - -![2016-09-16_18-38-15.gif]({{ base }}/assets/imgs/2016-09-16_18-38-15.gif) diff --git a/docs/_docs/artik-ide-plugin/artik-usb-connection-setup.md b/docs/_docs/artik-ide-plugin/artik-usb-connection-setup.md deleted file mode 100644 index 3333e409575..00000000000 --- a/docs/_docs/artik-ide-plugin/artik-usb-connection-setup.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Setup: ARTIK USB -excerpt: "" -layout: artik -permalink: /:categories/usb-connection-setup/ ---- -{% include base.html %} -After the workspace has been created, the first time that it is opened in the IDE, the ARTIK device discovery and management panel will appear. The workspace will manage your devices over SSH and configured by IP address. - -You can discover the IP address of USB-connected devices automatically using an embedded service powered by the Android Debug Bridge (ADB), which is running on the device and also has its client installed into your workspace. - -### Prerequisites for USB Discovery -The ADB daemon must be running on the device. Usually it is already running but if it's not or if you can't discover the device execute the following commands: -```shell -# On the device: Start the daemon -service adbd start - -# On the device: Have the daemon start upon device boot -systemctl enable adbd.service - -# In Che workspace: Verify that discovery is working -adb devices # Returns a discovered device\ -``` -Your Artik device must be connected over regular USB (do not use micro-USB). If ADB discovery service fails to find any USB-connected devices, a `No USB devices found` message will be displayed. If that happens please [post an issue to this GitHub issues](https://github.com/eclipse/che/issues) page. - -### Window User Using Boot2Docker with Virtualbox -On Windows machines using Boot2Docker and Virtualbox the USB controller must be enabled through Virtualbox Manager GUI: -- Stop the Boot2Docker machine. -- Select `USB 2.0 (EHCI) controller` in the Virtualbox UI and then hit the plus sign on the right. -- Make sure your ARTIK device is plugged in with a full size male to male USB cable and search for a USB device called `Android` and add it to the filter. -![Virtualboxaddusb.jpg]({{ base }}/assets/imgs/Virtualboxaddusb.jpg) diff --git a/docs/_docs/artik-ide-plugin/artik-wireless-setup.md b/docs/_docs/artik-ide-plugin/artik-wireless-setup.md deleted file mode 100644 index 8c385d5f97a..00000000000 --- a/docs/_docs/artik-ide-plugin/artik-wireless-setup.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Setup: Wireless -excerpt: "" -layout: artik -permalink: /:categories/wireless-setup/ ---- -{% include base.html %} diff --git a/docs/_docs/chedir-portable-workspaces/chedir-chefiles.md b/docs/_docs/chedir-portable-workspaces/chedir-chefiles.md deleted file mode 100644 index a2cef3b363b..00000000000 --- a/docs/_docs/chedir-portable-workspaces/chedir-chefiles.md +++ /dev/null @@ -1,147 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Chefile -excerpt: "Customize how the Che server, workspace, and project are generated from your project" -layout: docs -permalink: /:categories/chefiles/ ---- -{% include base.html %} -You can create a Chefile and place it into the root of your repository. The Chefile contains the configuration that will be used to setup the Che server and Che workspace. You can run `che dir init` in a directory to provide a template Chefile. - -```javascript -# This file can be generated by using `che dir init` -# Defines public IP for Che (ip should be IP of docker host) -che.server.ip = localhost - -# Defines port on which your private Che server will listen. -che.server.port = 8080 - -# Configure how Che boots with environment variables. -# Chefile supports the full Che configuration list: -# https://eclipse-che.readme.io/docs/configuration -che.server.properties['CHE_VERSION']='nightly' -che.server.properties['CHE_PROPERTY_http__proxy']='http://localhost:1234' - -# Defines name of the workspace -workspace.name = “happy” - -# Define the Docker image to use to power the workspace's runtime -# This must conform to: https://eclipse-che.readme.io/docs/recipes -workspace.runtime.image.location="eclispe/alpine_jdk8" - -# You can - instead - define the runtime using a Dockerfile in a git repo -workspace.runtime.docker.location= "http://gist...../my-dockerfile" - -# Or you could define the runtime using inline Dockerfile content -workspace.runtime.docker.dockerfile=` -FROM ... -RUN ... -ENV ... -` - -# Or, you can define a multi-contianer runtime using compose -workspace.runtime.docker.composefile=` -version: 2 -` - -# Defines memory allocated to the workspace's runtime -workspace.ram = 2048 - -# Commands are processes that users execute in the IDE. -# Commands will appear in the drop down on the tool bar. -workspace.commands[0].name = "my-first-command" -workspace.commands[0].type = "mvn" -workspace.commands[0].commandLine = "mvn clean install -f ${current.project.path}" -workspace.commands[0].attributes.previewUrl = "http://${server.port.80}/${current.project.relpath}" - -# If you omit the command type, it will default to a custom command (bash). -workspace.commands[1].name = "my-second-command" -workspace.commands[1].commandLine = "echo hello world" - -# A command that will be executed after the workspace is loaded. -# Reference the name of a command defined above. -workspace.postload.actions[0].name="my-second-command" - -# Or, by defining inline bash script within the post action. -workspace.postload.actions[1].script=`echo 'this is a post-loading command' \ - && while true; do \ - echo $(date); sleep 1; \ - done` - -# A project has type, name, and mapped to a source repository. -# This project is mapped to the directory where Chefile is saved. -workspace.projects[0].type="blank" - -# You can have multiple projects sourced from git or subversion repos -workspace.projects[1].name = "florent" -workspace.projects[1].source.type = "git" -workspace.projects[1].source.location = "https://github.com/che-samples/web-java-spring-petclinic" -workspace.projects[1].type = "maven" -``` - -# Sample Chefile -We maintain a [Chefile in the root of the Eclipse Che repository](https://github.com/eclipse/che/blob/master/Chefile). It is used to build and run Che using Eclipse Che! - -```javascript - -# Runtime image to use for booting and compiling Eclipse Che -# workspace.runtime.docker.image="florentbenoit/che-in-che" - -# Commands to display in the IDE -workspace.commands[0].name="build" -workspace.commands[0].commandLine="mvn clean install -f /projects/che/assembly/assembly-main" - - -workspace.commands[1].name="run" -workspace.commands[1].commandLine='export CHE_VERSION="nightly" && export CHE_BIN_PATH=$(ls -d /projects/che/assembly/assembly-main/target/eclipse-che-*/eclipse-che-*); sudo docker run --rm -t -v /var/run/docker.sock:/var/run/docker.sock' -workspace.commands[1].commandLine=workspace.commands[1].commandLine+" --env CHE_LOCAL_BINARY=${CHE_BIN_PATH/'/projects/che'/$(sudo docker inspect --format '{{"{{"}} range .Mounts }}{{"{{"}} if eq .Destination \"/projects/che\" }}{{"{{"}} .Source }}{{"{{"}} end }}{{"{{"}} end }}' $(hostname))}" -workspace.commands[1].commandLine=workspace.commands[1].commandLine+' --env CHE_PORT=54321 --env CHE_SERVER_CONTAINER_NAME="che-in-che-server" eclipse/che-launcher:nightly start' -workspace.commands[1].attributes={ - "previewUrl": "http://localhost:54321" -} - -workspace.commands[2].name="stop" -workspace.commands[2].commandLine='sudo docker run --rm -t -v /var/run/docker.sock:/var/run/docker.sock --env CHE_SERVER_CONTAINER_NAME="che-in-che-server" eclipse/che-launcher stop' - -workspace.commands[3].name="kill" -workspace.commands[3].commandLine="sudo docker rm -f che-in-che-server" - -# Name of the workspace -workspace.name="che" - -# Memory for this workspace -workspace.ram=3092 - -# Configure project properties -workspace.projects[0].type = "maven" -``` - -# Add Typescript to Chefile -Chefile is authored as Typescript. While it looks like a simple `name=value` property file, it's actually written entirely in Typescript using `variable=assignment` syntax. This means that you can add in valid TypeScript for variable assignments, operators, and constructs. - -This is essential for development team leads and developer operations teams so that they can dynamically generate the Chefile configuration as part of their continuous development processes. While complicated, this is also a valid Chefile: - -```javascript -var date = new Date(); -let es6Date = new Date(); - -let myMap = new Map(); -myMap.set("my-name\ "my-custom-workspace"); -myMap.set("my-ram\ 2048); - -console.log('first date is', date); -console.log('another date is', es6Date); - -console.log("map is\ myMap); - -workspace.name=getWorkspaceName(); -workspace.ram=myMap.get("my-ram"); - -console.log('first command of workspace is', workspace.commands[0].commandLine); - -function getWorkspaceName() { - return myMap.get("my-name"); -} -``` - -## NEXT STEPS diff --git a/docs/_docs/chedir-portable-workspaces/chedir-factories.md b/docs/_docs/chedir-portable-workspaces/chedir-factories.md deleted file mode 100644 index fcd96eb4d18..00000000000 --- a/docs/_docs/chedir-portable-workspaces/chedir-factories.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Factories -excerpt: "Convert Chefiles for execution by factories" -layout: docs -permalink: /:categories/factories/ ---- -{% include base.html %} -A factory is a Codenvy concept that automates the generation or loading of a workspace using URLs. Codenvy is a hosted version of Eclipse Che that you can deploy onto your own servers or make use of at Codenvy's systems at codenvy.com. - -Factories make it possible to execute many of the automation capabilities contained within a Chefile, but in a purely remote syntax. Factories are URLs that you give to others, that when executed by other developers, will generate new workspaces in those acceptors' accounts with cloned projects and ready-to-go commands. Factories are wrapped with policies so that the Factory owner can control when, how, and who is able to make use of the Factory without the acceptors' having to pre-configure any software on their computer. - -You can create Chefiles for a local directory from an existing Factory. Or, you can have Codenvy automatically generate a Factory for a source repository that has a Chefile in the root of the repository. Think of factory as a way for you to allow remote users to execute `che dir up` against a repository without those users having to install anything first. - -## Create Factory From Chefile -You can create a factory to load within Codenvy from an existing Chefile. In the directory that has your Chefile execute: -```shell -che dir factory\ -``` diff --git a/docs/_docs/chedir-portable-workspaces/chedir-getting-started.md b/docs/_docs/chedir-portable-workspaces/chedir-getting-started.md deleted file mode 100644 index b6ee4b1aafe..00000000000 --- a/docs/_docs/chedir-portable-workspaces/chedir-getting-started.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Getting Started -excerpt: "Convert any repository into a developer workspace." -layout: docs -permalink: /:categories/getting-started/ ---- -{% include base.html %} -The Chedir getting started guide will walk you through your first Chedir project, and show the basic features Chedir has to offer. - -If you are curious what benefits Chedir has to offer, you should also read the [Why Chedir?](https://eclipse-che.readme.io/docs/why-chedir) page. - -Before diving into your first workspace, please install the latest version of Chedir, which is also part of the [Eclipse Che CLI](https://eclipse-che.readme.io/docs/che-getting-started#0-pre-reqs). And since Docker is required for everything related to Che, make sure that is installed as well. -```shell -# For now, please use the nightly version of our utilities -export CHE_UTILITY_VERSION=nightly - -# Clone a source code repo that you want to convert into a workspace -git clone https://github.com/che-samples/web-java-spring-petclinic -cd web-java-spring-petclinic - -# Convert it into a workspace running in a private Che server -che dir up - -# Note: Currently requires no other Che servers to be running simultaneously -# New version coming will allow many directories mounted into a single server\ -``` -After running the above commands, you will have a project inside of a workspace inside of a running Che server. The workspace has its own runtime, powered by an Ubuntu Docker image. The project is mounted from the local directory into the workspace and is given full git capabilities. - -You can either open the IDE in your browser to work on the project immediately. The Web IDE has a terminal for accessing the Docker image powering the workspace. You can SSH into the workspace by pressing the `SSH` button in the IDE to get connectivity details. You can then make modifications, set the project type in the IDE, use language intellisense, or run a debugger. When you are done making modifications, you can use the IDE to commit and push changes with git, or continue to do those on your command line. You can then stop the workspace and unlink it with `che dir down`. - -Now imagine every repository that you work on being this easy to convert into a debuggable workspace that includes its own pre-configured IDE. Chedir is all you need to convert repositories into workspaces with their own private runtimes, dependencies, networking and synchronized folders. - -The rest of this guide will walk you through setting up a more complete project, covering more features of Chedir. - -## NEXT STEPS diff --git a/docs/_docs/chedir-portable-workspaces/chedir-installation.md b/docs/_docs/chedir-portable-workspaces/chedir-installation.md deleted file mode 100644 index 90553613fcf..00000000000 --- a/docs/_docs/chedir-portable-workspaces/chedir-installation.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Installation -excerpt: "Installing, upgrading and uninstalling Chedir" -layout: docs -permalink: /:categories/installation/ ---- -{% include base.html %} -Installing Chedir is extremely easy. Just [get the Che CLI](https://eclipse-che.readme.io/docs/che-getting-started#1-get-the-eclipse-che-cli) and you have everything you need to run Chedir on any operating system. Docker and Git Bash (installed by Docker) are required for the Che CLI. -# Backwards Compatibility -Chedir requires Eclipse Che 4.7+. Chefiles are not supported to run on older versions of Che. -# Upgrading -You will automatically get newer versions of Chedir when you upgrade Eclipse Che. You can upgrade Eclipse Che with the CLI by `che update`. If you want to use a particular version of Chedir you can set `CHE_VERSION` as an environment variable and Chedir will use that particular version. You can run multiple versions of Chedir at the same time. -# From Source -Chedir is provided as a Docker container which you can run instead of using the CLI. The CLI captures your environmental information and invokes the container with the appropriate syntax. -```shell -# Mac / Linux -docker run -v /var/run/docker.sock:/var/run/docker.sock \ - -v "$PWD":"$PWD" --rm eclipse/che-file \ - $PWD - -# Windows -# Replace $PWD to be the absolute path to the current directory. -# Use case-sensitive format with forward slashes: /c/Users/some_path/ -``` -# Build Chedir Docker Container -```shell -git clone http://github.com/eclipse/che-dockerfiles -cd che-dockerfiles -./lib/typescript/compile.sh && ./che-dir/build.sh\ -``` - -# Uninstallation -You can remove Chedir by deleting the Chedir docker image from your system. -```shell -docker rmi -f eclipse/che-dir\ -``` -If you'd also like to remove the Che CLI and Che: -```shell -# Remove the Che container -docker rmi -f eclipse/che-server - -# Remove your workspaces and the CLI - -# Linux / Mac -rm -rf $CHE_DATA_FOLDER -rm -rf /usr/local/bin/che - - -# Windows -rmdir /s %CHE_DATA_FOLDER% -del che.bat -del che.sh\ -``` diff --git a/docs/_docs/chedir-portable-workspaces/chedir-project-setup.md b/docs/_docs/chedir-portable-workspaces/chedir-project-setup.md deleted file mode 100644 index 9866183169c..00000000000 --- a/docs/_docs/chedir-portable-workspaces/chedir-project-setup.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Project Setup -excerpt: "" -layout: docs -permalink: /:categories/project-setup/ ---- -{% include base.html %} -The first step in configuring a Che workspace from your directory is to create a Chefile. The purpose of the Chefile is to: -1. Mark the root directory that contains the source code to be mounted into your workspace. This directory will be used to create a single project in the workspace running in the Che server. The project will be mounted into `/projects` in the workspace. Many of the configuration options in Chedir are relative to this root directory. - -2. Describe the way the Che server and workspace will be configured and the resources they need to run your project, as well as what workspace stack to use and how it should be accessed. - -Chedir has a built-in command for initializing a directory for usage with Chedir: `che dir init`. For the purpose of this getting started guide, please follow along in your terminal: -```shell -mkdir chedir_start -cd chedir_start -che dir init\ -``` -This will place a Chefile in your current directory. You can take a look at the Chefile if you want, it is filled with comments and examples. You can also run `che dir init` in a pre-existing directory that already has source code to set up Chedir for an existing project. - -The Chefile is meant to be committed to version control with your project, if you use version control. This way, every person working with that project can benefit from Chedir without any upfront work. - -## NEXT STEPS diff --git a/docs/_docs/chedir-portable-workspaces/chedir-ssh.md b/docs/_docs/chedir-portable-workspaces/chedir-ssh.md deleted file mode 100644 index bb60fbeaec7..00000000000 --- a/docs/_docs/chedir-portable-workspaces/chedir-ssh.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: SSH -excerpt: "SSH into your workspace" -layout: docs -permalink: /:categories/ssh/ ---- -{% include base.html %} -You can use Chedir to SSH into the newly created workspace, whether it is local or remote. It does not matter what operating system that you are using, this technique also supports Microsoft Windows without having to install putty! -```shell -che dir ssh\ -``` -The command has local context of the Che server and workspace that is associated with the Chefile in the current directory. Chedir looks up the appropriate context and then initiates an SSH connection. diff --git a/docs/_docs/chedir-portable-workspaces/chedir-up-and-down.md b/docs/_docs/chedir-portable-workspaces/chedir-up-and-down.md deleted file mode 100644 index 3bea28ca997..00000000000 --- a/docs/_docs/chedir-portable-workspaces/chedir-up-and-down.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Up and Down -excerpt: "Control the lifecycle of the workspace and Che server" -layout: docs -permalink: /:categories/up-and-down/ ---- -{% include base.html %} -In the first version of Chedir, each Chedir directory maps to a single Che server containing a single workspace. That workspace can have multiple projects and source repositories that are part of it. - -You can boot both a Che server and a worskpace (with its embedded runtimes) with a single command: -```shell -che dir up\ -``` -This command will boot a Che server according to the properties in the Chefile. If necessary, the right Che launcher and Che server Docker images will be downloaded and cached. After the server has booted, Chedir will create a workspace and start its runtime, also as a set of Docker containers. - -If there is an existing Che server running with the configuration specified, Chedir will discontinue and recommend that you create a different configuration to avoid conflicts. In a future version of Chedir, we'll allow creating additional workspaces in an existing Che server, or even in a remote one such as at Codenvy. - -When the process of creation has completed, you will be presented with two URLs: -1: Che server URL - a URL that will open the dashboard to manage the Che instance -2: Workspace URL - a URL that will open the browser IDE with the workspace configured - -The workspace is a fully functional runtime environment. You can work within the workspace, SSH into it, and also work on code. Any code changes will be synchronized with the local directory. You can also perform git operations such as add, commit, and push from within the IDE. - -When you are done working on the workspace, you can suspend the workspace and have it snapshot. -```shell -che dir down\ -``` -Run `che dir down` on the host machine. Chedir will stop the workspace's runtime, stop the Che server, and return to the host. The workspace and its project will be preserved. You can run `che dir up` to reactivate it. This command is the equivalent of running `che stop` with the CLI. - -To stop the Che server and remove the workspace, you can destroy it. -```shell -che dir destroy\ -``` -## NEXT STEPS diff --git a/docs/_docs/chedir-portable-workspaces/chedir-why.md b/docs/_docs/chedir-portable-workspaces/chedir-why.md deleted file mode 100644 index 243da077b09..00000000000 --- a/docs/_docs/chedir-portable-workspaces/chedir-why.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Why Chedir? -excerpt: "Create and configure reproducible and portable developer workspaces." -layout: docs -permalink: /:categories/why/ ---- -{% include base.html %} -Chedir provides easy to configure, reproducible and portable developer workspaces built on top of Docker and controlled by a single consistent workflow to help maximize the productivity and flexibility of you and your team. - -To achieve its magic, Chedir uses Eclipse Che and Docker. Workspaces are provisioned inside of a Che server that is running locally or remotely. The workspace will have its own private runtime that is also based upon Docker or Docker Compose. Your source code is then synchronized from the current directory into the hosted workspace. You can then use provisioning tools such as shell scripts, Chef, or Puppet to define the software that is inside the workspace available to edit, build, run and debug your code. - -Chedir is (positively) influenced by Vagrant. Where Vagrant treats a single VM as a broad abstraction as an "environment", Chedir applies a similar abstraction to a developer workspace, which is inclusive of multiple internal environments, the source code for projects mapped from repositories, and the tools + commands necessary to build and debug a project. After provisioning, users can connect their local IDE or use the embedded cloud IDE of Eclipse Che. diff --git a/docs/_docs/index.html b/docs/_docs/index.html deleted file mode 100644 index 8f2a54376c4..00000000000 --- a/docs/_docs/index.html +++ /dev/null @@ -1,90 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -layout: default -overview: true -permalink: /docs/ ---- - -{% include base.html %} -
-
-
-

Cloud workspaces for development teams.

-
-
-
-
-
- - - -
-
-
-
-
-
-

Get up and running in seconds.

-
-
-

Quick-start Instructions

-
-

- ~ - $ - gem install jekyll bundler -

-

- ~ - $ - jekyll new my-awesome-site -

-

- ~ - $ - cd my-awesome-site -

-

- ~/my-awesome-site - $ - bundle exec jekyll serve -

-

- # => Now browse to http://localhost:4000 -

-
-
-
-
-
-
-
-
-
-
-
-

Replace Title ...

-

Replace content

-
-
-
-
-
-
-
diff --git a/docs/_docs/openshift-plugin/openshift-config.md b/docs/_docs/openshift-plugin/openshift-config.md deleted file mode 100644 index 3f35bca0c17..00000000000 --- a/docs/_docs/openshift-plugin/openshift-config.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Openshift Install -excerpt: "How to install the OpenShift Plug-in." -layout: openshift -permalink: /:categories/config/ ---- -{% include base.html %} -# Download -### Binaries -[Get packaged zip file](http://maven.codenvycorp.com/content/repositories/codenvy-public-snapshots/org/eclipse/che/openshift-plugin-assembly-main/) - -### Build From Source -```shell -git clone https://github.com/codenvy/plugin-openshift -cd plugin-openshift -mvn clean install\ -``` - -# Configure Che - -```shell -# Create a directory to host conf files -mkdir -p /home/user/.che/plugin-conf - -# Set CHE_LOCAL_CONF_DIR to be this new folder -echo "export CHE_LOCAL_CONF_DIR=/home/user/.che" >> ~/.bashrc -``` -Create `~/.che/che.properties` and set OpenShift parameters. -```toml -openshift.api.endpoint=https://your.openshift.instance.com/ -oauth.openshift.authuri=https://your.openshift.instance.com/oauth/authorize -oauth.openshift.tokenuri=https://your.openshift.instance.com/oauth/token -oauth.openshift.clientid=yourID -oauth.openshift.clientsecret=yourSecret -oauth.openshift.redirecturis=http://localhost:${SERVER_PORT}/wsmaster/api/oauth/callback\ -``` -Create `~/.che/plugin-conf/che.properties` and set a single OpenShift parameter: -```toml -openshift.api.endpoint=https://your.openshift.instance.com/\ -``` -Both configuration files are mandatory. -#### What is my API endpoint client ID and secret? -API endpoint is the URL of your OpenShift installation (can be a domain name or IP address). Client ID and secret should match those registered in a [custom oAuth client](#register-a-custom-oauth-client). - - -# Register a Custom oAuth Client -Che uses oAuth2 to get authentication tokens from OpenShift. You need to register a custom oAuth client in your OpenShift master node. Example, using `oc`: -```shell -# Requires OpenShift admin privs -oc create -f <(echo ' -{ - "kind": "OAuthClient\n "apiVersion": "v1\n "metadata": { - "name": "che" - }, - "secret": "yoursecret\n "redirectURIs": [ - "http://localhost:8080/wsmaster/api/oauth/callback" - ] -}') -``` diff --git a/docs/_docs/openshift-plugin/openshift-user-guide.md b/docs/_docs/openshift-plugin/openshift-user-guide.md deleted file mode 100644 index c7a7a49c86f..00000000000 --- a/docs/_docs/openshift-plugin/openshift-user-guide.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: OpenShift Use -excerpt: "How to use the OpenShift plug-in." -layout: openshift -permalink: /:categories/user-guide/ ---- -{% include base.html %} -# Run Che - -```shell -# if you downloaded binaries -/bin/che.sh run - -# if you built Che from source - -assembly/openshift-plugin-assembly-main/target/eclipse-che-${version}/eclipse-che-${version}/bin/che.sh run\ -``` -Che will be available at `http://localhost:8080` -# Connect Account -Login to your account **OpenShift > Connect Account**. You will retrieve a token using authentication method set up for your OpenShift installation (login/password, Google oAuth etc). -# Create Application From Template -Create a new app from a template at **OpenShift > Create Application From Template**. This will both create a new OpenShift project (namespace) and a set of configs, as well as import an app into Che. - -Once an app is imported, OpenShift metadata is added to project attributes, thus a connection between Che and OpenShift resources is established. -#### Import a Module -} - - -![module.png]({{ base }}/assets/imgs/module.png) - -#### Development cycle -Since projects created from OpenShift templates use GitHub repositories that you cannot push to, use templates just for demo purposes. Alternatively, you may replace Git URL in *buildConfig* with the one you have push permissions at `OpenShift > Manage Configs`. - - -# Import Existing OpenShift App -When importing an existing OpenShift application, the plugin checks for all *buildConfigs* in all user namespaces, extracts Git URLs and shows them in the application list, grouped by a namespace. -# Deploy Existing App to OpenShift -Deployment to OpenShift triggers two actions: marking Che project as OpenShift project type and creating a set of objects on the OpenShift side. - -A user can choose/edit: - -* namespace where all the objects will be created (new vs existing one) -* builder image, i.e. where the code will be compiled (if applicable) and deployed with an app server -* environment variables/labels and their values - -You'll need to enter both project and application names. -# Link Che App With Existing OpenShift App / Unlink App -Che projects can be linked with existing OpenShift applications at **OpenShift > Deploy > Link With Existing App**. When a Che project is linked to OpenShift application, OpenShift metadata is saved to Che project attributes (namespace and label). - -It is possible to `'unlink'` Che project from OpenShift, which means clearing Che project attributes. Unlinking project does not delete OpenShift namespace and its associated resources. -# Delete OpenShift Project -It is possible to delete an OpenShift project only when a related Che project is selected in a project tree. Deleting OpenShift project resets Che project (OpenShift attributes are removed) and deletes OpenShift namespace. - -If an OpenShift namespace has multiple `buildConfigs` (apps), a user will be prompted to confirm namespace deletion. Warning message will contain the list of resources that will be deleted. -# Get Webhooks -GitHub and generic Git webhooks make it possible to notify OpenShift that a Git repo has been updated. Git push will trigger a new build in OpenShift, and a `buildConfig` will clone updated source code. Webhooks are retrieved at `OpenShift > Manage Configs > Build`. -# Show Appication URL -If a project has been deployed to OpenShift, linked with existing app or imported an as existing OpenShift application, it is possible to get preview URL of a running app (get route) at `OpenShift > Manage Configs > Route`. -# Trigger Build -`OpenShift > Start Build` will initiate a new build, subscribe to Websocket channels to track build status and stream build logs. - -Che will also listen to other build channels, and if a build has been triggered (not necessarily from Che), build logs will be streamed to a dedicated panel. -# Add A Database -Databases can be added at `OpenShift > Services > Add Service`. - -OpenShift Plugin will look for database templates in `openshift` namespace and all user namespaces, let a user edit/add environment variables (username, password, databasename) create objects listed in a template, and add database pod environment variables to application `deploymentConfig`. -#### Database Templates -The plugin filters templates by `database` tag. If you database templates do not have this tag, they will not be listed in the popup. - - -# How to Connect to a Database Pod -Pods use environment variables for communication. Some env variables are shared across all pods running in the same namespace, while others are added to application `deploymentConfig` when a database pod is created. - -Having added a database, connect to it, using environment variables. - -A few examples: -```java -System.getenv("MYSQL_USER") -``` - -```php -$servername = getenv("MYSQL_PORT_3306_TCP_ADDR"); -``` diff --git a/docs/_docs/setup/che-setup-bitnami.md b/docs/_docs/setup/che-setup-bitnami.md deleted file mode 100644 index 0aa360e3f80..00000000000 --- a/docs/_docs/setup/che-setup-bitnami.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Getting Started: Private Cloud -excerpt: "Using Che with your cloud hosting account." -layout: docs -permalink: /:categories/bitnami/ ---- -{% include base.html %} -Bitnami provides provides a [one-click install](https://bitnami.com/stack/eclipse-che) solution for deploying Eclipse Che to your own cloud account. -# 1. Install Che -Bitnami will automatically install Che to your cloud account, just select your provider and then choose "Add Account" from the menu: -![ScreenShot2016-06-23at9.40.42AM.png]({{ base }}/assets/imgs/ScreenShot2016-06-23at9.40.42AM.png) -Once your account is connected select the instance size. You should ensure that Che has at least 4GB RAM and 10GB of storage (the Che server itself will need ~2GB RAM). If you plan on running larger or more workspaces, increase your RAM and storage. -#### Azure Ports -} - - -# 2. Usage -When your private Che cloud server is ready you will see a page like the following: -![ScreenShot2016-11-30at12.40.15PM.png]({{ base }}/assets/imgs/ScreenShot2016-11-30at12.40.15PM.png) -In the Credentials section you'll find your username and password. Show the password and copy it to the clipboard. When you click on the IP address for the Che server on this page you will be brought to a welcome page from Bitnami. When you select the login link you will be asked for a username and password. Type the username and paste the password into the form. - -You should now have access to the Che user dashboard. - -These are some other common URLs on your instance: -```text -/ # Loads dashboard or last opened workspace -/dashboard # Loads dashboard -/ide/ # Loads specific workspace -/ide/ # Opens IDE with a prompt to create a new workspace -/ide # Loads the IDE, bypassing the dashboard\ -``` -## Running, Stopping and Restarting Che -If you have SSH access to the Che instance you can start and stop Che from the command line. -```shell -# to start Che -sudo su eclipseche -- /opt/bitnami/apps/eclipseche/che/bin/che.sh -p:8080 -s:uid start - -# to stop Che -sudo su eclipseche -- /opt/bitnami/apps/eclipseche/che/bin/che.sh -p:8080 -s:uid stop\ -``` -Controlling the instance hosting Che is done through your cloud provider's management console. - -## Preserving Project Files -All of your configuration files, workspaces, and projects are stored on the instance file system. These files won't be lost when you stop the machine normally from your cloud provider's console. - -If you destroy the instance hosting Che, your workspace and preferences will be lost. If you want to migrate or preserve those settings you can SSH into the instance and copy everything in `opt/bitnami/apps/eclipseche`. - -## Changing the Password -Passwords are stored in a file at `/opt/bitnami/apps/eclipseche/conf/.htpasswd` and the default user is `user`. The user and password can be updated using Apache's `htpasswd` command. - -To change the password: -1. Access the server using an [SSH connection](https://docs.bitnami.com/azure/faq/#how-to-connect-to-the-server-through-ssh) - -2. Change the contents of `/opt/bitnami/apps/eclipseche/conf/.htpasswd` to include the password you want to use. - -3. Run the following command substituting `new_user` for your preferred user name: -```text -sudo /opt/bitnami/apache2/bin/htpasswd /opt/bitnami/apps/eclipseche/conf/.htpasswd new_user\ -``` - -#### Advanced Configuration -There are many aspects of Eclipse Che like port and hostname that can be configured by [setting Eclipse Che properties](https://eclipse-che.readme.io/docs/usage-docker#environment-variables). - - -# 3. Develop with Che -Now that Che is running there are a lot of fun things to try: -- Become familiar with Che through [one of our tutorials](https://eclipse-che.readme.io/docs/get-started-with-java-and-che). -- [Import a project](https://eclipse-che.readme.io/docs/import-a-project) from git. -- Use [commands](https://eclipse-che.readme.io/docs/commands) to build and run a project. -- Create a [preview URL](https://eclipse-che.readme.io/docs/previews) to share your app. -- Setup a [debugger](https://eclipse-che.readme.io/docs/debug). -- Experiment with [chedir](https://dash.readme.io/project/eclipse-che/docs/getting-started-chedir). -- Create a [custom stack](https://eclipse-che.readme.io/docs/stacks). diff --git a/docs/_docs/setup/che-setup-cli.md b/docs/_docs/setup/che-setup-cli.md deleted file mode 100644 index 05674948435..00000000000 --- a/docs/_docs/setup/che-setup-cli.md +++ /dev/null @@ -1,213 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: CLI Reference -excerpt: "Manage your Che installation on the command line." -layout: docs -permalink: /:categories/cli/ ---- -{% include base.html %} -The Docker image which runs Che is the Che CLI. It has various commands for running Che and also for allowing your end users to interact with their workspaces on the command line. - -``` -USAGE: - docker run -it --rm eclipse/che-cli: [COMMAND] - -MANDATORY DOCKER PARAMETERS: - -v :/data Where user, instance, and log data saved - -OPTIONAL DOCKER PARAMETERS: - -e CHE_HOST= IP address or hostname where che will serve its users - -e CHE_PORT= Port where che will bind itself to - -v :/data/instance Where instance, user, log data will be saved - -v :/data/backup Where backup files will be saved - -v :/repo che git repo to activate dev mode - -v :/sync Where remote ws files will be copied with sync command - -v :/unison Where unison profile for optimzing sync command resides - -COMMANDS: - action Start action on che instance - backup Backups che configuration and data to /data/backup volume mount - config Generates a che config from vars; run on any start / restart - destroy Stops services, and deletes che instance data - dir Use Chefile feature in the directory - download Pulls Docker images for the current che version - help This message - info Displays info about che and the CLI - init Initializes a directory with a che install - offline Saves che Docker images into TAR files for offline install - restart Restart che services - restore Restores che configuration and data from /data/backup mount - rmi Removes the Docker images for , forcing a repull - ssh [machine-name] SSH to a workspace if SSH agent enabled - start Starts che services - stop Stops che services - sync Synchronize workspace with current working directory - test Start test on che instance - upgrade Upgrades che from one version to another with migrations and backups - version Installed version and upgrade paths -``` - -The CLI will hide most error conditions from standard out. Internal stack traces and error output is redirected to `cli.log`, which is saved in the host folder where `:/data` is mounted. - -## init -Initializes an empty directory with a Che configuration and instance folder where user data and runtime configuration will be stored. You must provide a `:/data` volume mount, then Che creates a `instance` and `backup` subfolder of ``. You can optionally override the location of `instance` by volume mounting an additional local folder to `/data/instance`. You can optionally override the location of where backups are stored by volume mounting an additional local folder to `/data/backup`. After initialization, a `che.env` file is placed into the root of the path that you mounted to `/data`. - -These variables can be set in your local environment shell before running and they will be respected during initialization: - -| Variable | Description | -|----------|-------------| -| `CHE_HOST` | The IP address or DNS name of the Che service. We use `eclipse/che-ip` to attempt discovery if not set. | - -Che depends upon Docker images. We use Docker images to: -1. Provide cross-platform utilites within the CLI. For example, in scenarios where we need to perform a `curl` operation, we use a small Docker image to perform this function. We do this as a precaution as many operating systems (like Windows) do not have curl installed. -2. Look up the master version and upgrade manifest, which is saved within the CLI docker image in the /version subfolder. -3. Perform initialization and configuration of Che such as with `eclipse/che-init`. This image contains templates to be installed onto your computer used by the CLI to configure Che for your specific OS. - -You can control how Che downloads these images with command line options. All image downloads are performed with `docker pull`. - -| Mode>>>>>>>>>>>> | Description | -|------|-------------| -| `--no-force` | Default behavior. Will download an image if not found locally. A local check of the image will see if an image of a matching name is in your local registry and then skip the pull if it is found. This mode does not check DockerHub for a newer version of the same image. | -| `--pull` | Will always perform a `docker pull` when an image is requested. If there is a newer version of the same tagged image at DockerHub, it will pull it, or use the one in local cache. This keeps your images up to date, but execution is slower. | -| `--force` | Performs a forced removal of the local image using `docker rmi` and then pulls it again (anew) from DockerHub. You can use this as a way to clean your local cache and ensure that all images are new. | -| `--offline` | Loads Docker images from `backup/*.tar` folder during a pre-boot mode of the CLI. Used if you are performing an installation or start while disconnected from the Internet. | - -You can reinstall Che on a folder that is already initialized and preserve your `che.env` values by passing the `--reinit` flag. - -## config -Generates a Che instance configuration thta is placed in `/instance`. This command uses puppet to generate Docker Compose configuration files to run Che and its associated server. Che's server configuration is generated as a che.properties file that is volume mounted into the Che server when it boots. This command is executed on every `start` or `restart`. - -If you are using a `eclipse/che-cli:` image and it does not match the version that is in `/instance/che.ver`, then the configuration will abort to prevent you from running a configuration for a different version than what is currently installed. - -This command respects `--no-force`, `--pull`, `--force`, and `--offline`. - -## start -Starts Che and its services using `docker-compose`. If the system cannot find a valid configuration it will perform an `init`. Every `start` and `restart` will run a `config` to generate a new configuration set using the latest configuration. The starting sequence will perform pre-flight testing to see if any ports required by Che are currently used by other services and post-flight checks to verify access to key APIs. - -## stop -Stops all of the Che service containers and removes them. - -## restart -Performs a `stop` followed by a `start`, respecting `--pull`, `--force`, and `--offline`. - -## destroy -Deletes `/docs`, `che.env` and `/instance`, including destroying all user workspaces, projects, data, and user database. If you pass `--quiet` then the confirmation warning will be skipped. Passing `--cli` will also destroy the `cli.log`. By default this is left behind for traceability. - -## offline -Saves all of the Docker images that Che requires into `/backup/*.tar` files. Each image is saved as its own file. If the `backup` folder is available on a machine that is disconnected from the Internet and you start Che with `--offline`, the CLI pre-boot sequence will load all of the Docker images in the `/backup/` folder. - -`--list` option will list all of the core images and optional stack images that can be downloaded. The core system images and the CLI will always be saved, if an existing TAR file is not found. `--image:` will download a single stack image and can be used multiple times on the command line. You can use `--all-stacks` or `--no-stacks` to download all or none of the optional stack images. - -## rmi -Deletes the Docker images from the local registry that Che has downloaded for this version. - -## download -Used to download Docker images that will be stored in your Docker images repository. This command downloads images that are used by the CLI as utilities, for Che to do initialization and configuration, and for the runtime images that Che needs when it starts. This command respects `--offline`, `--pull`, `--force`, and `--no-force` (default). This command is invoked by `che init`, `che config`, and `che start`. - -`download` is invoked by `che init` before initialization to download images for the version specified by `eclipse/che-cli:`. - -## version -Provides information on the current version and the available versions that are hosted in Che's repositories. `che upgrade` enforces upgrade sequences and will prevent you from upgrading one version to another version where data migrations cannot be guaranteed. - -## upgrade -Manages the sequence of upgrading Che from one version to another. Run `che version` to get a list of available versions that you can upgrade to. - -Upgrading Che is done by using a `eclipse/che-cli:` that is newer than the version you currently have installed. For example, if you have 5.0.0-M2 installed and want to upgrade to 5.0.0-M7, then: -``` -# Get the new version of Che -docker pull eclipse/che-cli:5.0.0-M7 - -# You now have two eclipse/che-cli images (one for each version) -# Perform an upgrade - use the new image to upgrade old installation -docker run eclipse/che-cli:5.0.0-M7 upgrade -``` - -The upgrade command has numerous checks to prevent you from upgrading Che if the new image and the old version are not compatiable. In order for the upgrade procedure to proceed, the CLI image must be newer than the value of '/instance/che.ver'. - -The upgrade process: a) performs a version compatibility check, b) downloads new Docker images that are needed to run the new version of Che, c) stops Che if it is currently running triggering a maintenance window, d) backs up your installation, e) initializes the new version, and f) starts Che. - -You can run `che version` to see the list of available versions that you can upgrade to. - -## info -Displays system state and debugging information. `--network` runs a test to take your `CHE_HOST` value to test for networking connectivity simulating browser > Che and Che > workspace connectivity. - -## backup -TARS your `/instance` into files and places them into `/backup`. These files are restoration-ready. - -## restore -Restores `/instance` to its previous state. You do not need to worry about having the right Docker images. The normal start / stop / restart cycle ensures that the proper Docker images are available or downloaded, if not found. - -This command will destroy your existing `/instance` folder, so use with caution, or set these values to different folders when performing a restore. - -## action -Executes some actions on the Eclipse Che instance or on a workspace running inside Che. -For example to list all workspaces on Che, the following command can be used -`action list-workspaces`. -To execute a command on a workspace `action execute-command ` where action can be any bash command. - -## dir -Boots a new Eclipse Che instance with a workspace for the folder specified in parameter. -If for example `$HOME/my-project` is given as parameter in `dir $HOME/my-project up`, a new Che instance will be created, using `$HOME/my-project`as project in the IDE. -So inside the IDE, `/projects` folder will contain a `my-project`folder with your host folder. -Then, any changes inside the IDE will be reflected in your host folder. And the opposite is also true, updating a file on your local computer will update the content of the file inside the IDE. - -Other commands are `init`,`up`, `down`, `ssh` and `status` - - - `init` : Initialize the directory specified and add a default `Chefile` file if there is none - - `up` : Boot Eclipse Che with workspace on folder - - `down` : Stop Eclipse Che and any workspaces - - `ssh` : Connect to the running workspace by using ssh - - `status`: Display if an instance of Eclipse Che is running or not for the specified folder. - -## ssh -Connects the current terminal where the command is started to the terminal of a machine of the workspace. If no machine is specified in the command, it will connect to the default machine which is the dev machine. -The syntax is `ssh [machine-name]` -The ssh connection will work only if there is a workspace ssh key setup. A default ssh key is automatically generated when a workspace is created. - -## test -Performs some tests on your local instance of Che. It can for example check the ability to create a workspace, start the workspace by using a custom Workspace runtime and then use it. -The list of all the tests available can be obtained by providing only `test` command. - -# CLI Development -You can customize the CLI using a variety of techniques. This section discusses how engineers develop and test the CLI on their local machines. - -## Structure -The Che CLI is constructed of multiple Docker images within the Che source repository. -``` -/dockerfiles/base # Common functions and commands -/dockerfiles/cli # CLI entrypoint, overrides, and version information -/dockerfiles/init # Manifests used to configure Che on a host installation -``` - -The Che CLI is authored in `bash`. The `cli` image depends upon both the `base` image and the `init` image. In the source repository, we have `build.sh` commands which will build these Docker images for you either one at a time or collectively as a group. - -It can become tedious rebuilding images every time you want to test a small change to a bash script. You can avoid having to rebuild images each time for every change to a bash script by volume mounting the contents during the image execution. You cannot volume mount the `entrypoint.sh` file which is where each container has a launch point, but you can volume mount others: -``` -# Volume mount the contents of the base image --v /dockerfiles/scripts/base/scripts:/base/scripts - -# Volume mount the contents of the init image --v :/repo -``` - -If you run the Che CLI in this configuration, then any changes made to the bash files or templates in those repositories will be used without having to first rebuild the CLI image. - -## Custom CLI Assemblies -The Che CLI was designed to easily be overridden to allow different CLIs to be created from the same base structure. This is how Codenvy and ARTIK has an identical CLIs to Che. The CLI is created with a few minimal assets: -``` -/dockerfiles/cli/build.sh # Local file to build the image -/dockerfiles/cli/Dockerfile # Image definition, must FROM eclipse/che-base:nightly -/dockerfiles/cli/scripts # Contains additional commands in form of cmd_.sh -/dockerfiles/cli/scripts/entrypoint.sh # The entrypoint of the CLI container, with usage() method -/dockerfiles/cli/scripts/cli.sh # Defines CLI-specific product names & variables -/dockerfiles/cli/version # Contains version-specific data the CLI requires -``` - -You can add additional commands to the Che CLI beyond the base set of commands that are provided by adding a file of the name `cmd_.sh` into the `scripts` folder. Codenvy is an [example that adds additional commands](https://github.com/codenvy/codenvy/tree/master/dockerfiles/cli/scripts). - -The `version` folder has information that details the latest version and a sub-folder for each version that is available for installation. Each version subfolder has version-specific data that the CLI depends upon to create a manifest of Docker images that must be downloaded to support the product that is going to be run. When we generate a release of the Che CLI, we have our CI systems automatically update the `/version` folder with the version-specific information contained in a release. - -## Puppet Templates -The Che CLI uses Puppet to generate OS-specific configuration files based upon environment variables set by the user either with `-e ` options on the command line, or by modifying their `che.env` file. We pass all of these values into Puppet and then run a puppet configuration utility across the files contained in the `/dockerfiles/init/modules` and `/dockerfiles/init/manifests` folder to take the templates contained within the `/init` module, marry them with user-specific variables, and then generate an instance-specific configuration in `/instance`. Puppet has logic constructs that allow us to generate different kinds of constructs with logic based upon the values provided by end users. - -This puppet-based approach allow us to simplify the outputs for end users and limit the locations where end users need to configure various parts of the system. One powerful example of this is that we generate two `docker-compose.yml` files from a single Puppet template. In the user's `/instance` folder is `docker-compose.yml` and `docker-compose-container.yml`. The first one is a configuration file that allows a user to run Docker compose for Che on their host. They can just `docker-compose up` in that folder. The second file is for running Docker compose from within a container, which is what the CLI does. The syntax of Docker compose changes in each of these scenarios as the files being referenced from within the compose syntax are different. In the `init` image, we have a single template for Docker Compose and then apply it in two configurations using Puppet. diff --git a/docs/_docs/setup/che-setup-configuration.md b/docs/_docs/setup/che-setup-configuration.md deleted file mode 100644 index 2f3c1a7a483..00000000000 --- a/docs/_docs/setup/che-setup-configuration.md +++ /dev/null @@ -1,283 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Configuration -excerpt: "Configure Eclipse Che to bend to your will..." -layout: docs -permalink: /:categories/configuration/ ---- -{% include base.html %} -Configuration is handled by modifying `che.env` placed in the host folder volume mounted to `:/data`. This configuration file is generated during the `che init` phase. If you rerun `che init` in an already initialized folder, the process will abort unless you pass `--force`, `--pull`, or `--reinit`. - -Each variable is documented with an explanation and usually commented out. If you need to set a variable, uncomment it and configure it with your value. You can then run `che config` to apply this configuration to your system. `che start` also reapplies the latest configuration. - -You can run `che init` to install a new configuration into an empty directory. This command uses the `che/init:` Docker container to deliver a version-specific set of puppet templates into the folder. - -If you run `che config`, che runs puppet to transform your puppet templates into a che instance configuration, placing the results into `/che/instance` if you volume mounted that, or into a `instance` subdirectory of the path you mounted to `/che`. Each time you start che, `che config` is run to ensure instance configuration files are properly generated and consistent with the configuration you have specified in `che.env`. - -# Saving Configuration in Version Control -Administration teams that want to version control your che configuration should save `che.env`. This is the only file that should be saved with version control. It is not necessary, and even discouraged, to save the other files. If you were to perform a `che upgrade` we may replace these files with templates that are specific to the version that is being upgraded. The `che.env` file maintains fidelity between versions and we can generate instance configurations from that. - -The version control sequence would be: -1. `che init` to get an initial configuration for a particular version. -2. Edit `che.env` with your environment-specific configuration. -3. Save `che.env` to version control. -4. Setup a new folder and copy `che.env` from version control into the folder you will mount to `:/data`. -5. Run `che config` or `che start`. - -# Internal Configuration -We provide a complete list of user-configurable properties in the `che.env` file. However, there are additional internal Che server properties that can also be configured. When we start the `che-server` Docker container, it is configured with a `che.properties` file to define a variety of internal operational details. You can [view the default file](https://github.com/eclipse/che/blob/08344fe62ebedfaa199e3258279b29acec7c88f8/assembly/assembly-wsmaster-war/src/main/webapp/WEB-INF/classes/codenvy/che.properties) in our GitHub repo. - -You can override these properties or pass in new Che server properties by defining additional environment variables within `che.env`. The CLI will convert any `che.env` additional properties into custom `che.properties` that are passed into the server. - -Any variable with the format `CHE_PROPERTY_=` will be configured into property value. A single underscore `_` will be converted into a period `.`. A double underscore `__` will be converted into a single underscore `_`. For example: -```shell -# This environment variable: -CHE_PROPERTY_machine_ws__agent_max__start__time__ms=1000 - -# Is sent to the Che server as: -machine.ws_agent.max_start_time_ms=1000 -``` - -# Logs and User Data -When Che initializes itself, it stores logs, user data, database data, and instance-specific configuration in the folder mounted to `:/data/instance` or an `instance` subfolder of what you mounted to `:/data`. - -Che's containers save their logs in the same location: -```shell -/instance/logs/che/2016 # Server logs -/instance/logs/che/che-machine-logs # Workspace logs -``` - -User data is stored in: -```shell -/instance/data/che # Project backups (we synchronize projs from remote ws here) -``` - -Instance configuration is generated by Che and is updated by our internal configuration utilities. These 'generated' configuration files should not be modified and stored in: -```shell -/instance/che.ver.do_not_modify # Version of che installed -/instance/docker-compose-container.yml # Docker compose to launch Che from within a container -/instance/docker-compose.yml # Docker compose to launch Che from the host without contianer -/instance/config # Configuration files for Che which are volume mounted into containers -``` - -# oAuth -You can configure Google, GitHub, Microsoft, BitBucket, or WSO2 oAuth for use when users perform git operations. - -Che is shipped with a preconfigured GitHub oAuth application for the `che.onprem` hostname. To enable GitHub oAuth, add `che_HOST=che.onprem` to `che.env` and restart. If you have a custom DNS, you need to register a GitHub oAuth application with GitHub's oAuth registration service. You will be asked for the callback URL, which is `http:///api/oauth/callback`. You will receive from GitHub a client ID and secret, which must be added to `che.env`: -``` -CHE_GITHUB_CLIENT_ID=yourID -CHE_GITHUB_SECRET=yourSecret -``` - -Google oAuth (and others) are configured the same: -``` -CHE_GOOGLE_CLIENT_ID=yourID -CHE_GOOGLE_SECRET=yourSecret -``` - -#### GitHub oAuth -Refer to [GitHub using OAuth]() for configuration information. - -#### GitLab oAuth -Refer to [GitHub using OAuth]() for configuration information. - - -# Stacks -[Stacks]() define the recipes used to create workspace runtimes. They appear in the stack library of the dashboard. You can create your own. - -TODO: UPDATE THIS -ONE: WHERE ARE STACKS DEFINED FOR CONFIGURATION PURPOSES WITH NEW CLI? -TWO: LINK TO DOC ON ADDING OR REMOVING - -# Sample Projects -Code [sampes]() allow you to define sample projects that are cloned into a workspace if the user chooses it when creating a new project. You can add your own. - -TODO: UPDATE THIS FOR THE NEW LOCATION WITH THE CLI ON HOW TO ADD - -# Development Mode -For che developers that are building and customizing che from its source repository, you can run che in development mode where your local assembly is used instead of the one that is provided in the default containers downloaded from DockerHub. This allows for a rapid edit / build / run cycle. - -Dev mode is activated by volume mounting the che git repository to `:/repo` in your Docker run command. -``` -docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock \ - -v :/data \ - -v :/repo \ - eclipse/che-cli: [COMMAND] -``` -Dev mode will use files from your host repository: - -1. During the `che config` phase, the source repository's `/dockerfiles/init/modules` and `/dockerfiles/init/manifests` will be used instead of the ones that are included in the `eclipse/che-init` container. -2. During the `che start` phase, a local assembly from `assembly/assembly-main/target/` is mounted into the `eclipse/che-server` runtime container. You must `mvn clean install` the `assembly/assembly-main/` folder prior to activating development mode. - -To activate jpda suspend mode for debugging Che server initialization, in the `che.env`: -``` -CHE_DEBUG_SUSPEND=true -``` -To change che debug port, in the `che.env`: -``` -CHE_DEBUG_PORT=8000 -``` - -# Hostname -The IP address or DNS name of where the Che endpoint will service your users. If you are running this on a local system, we auto-detect this value as the IP address of your Docker daemon. On many systems, especially those from cloud hosters like DigitalOcean, you may have to explicitly set this to the external IP address or DNS entry provided by the provider. You can edit this value in `che.env` and restart Che, or you can pass it during initialization: - -``` -docker run -e CHE_HOST= eclipse/che-cli: start -``` - -# Workspace Limits -You can place limits on how users interact with the system to control overall system resource usage. You can define how many workspaces created, RAM consumed, idle timeout, and a variety of other parameters. See "Workspace Limits" in `che.env`. - -You can also set limits on Docker's allocation of CPU to workspaces, which may be necessary if you have a very dense workspace population where users are competing for limited physical resources. - -# Docker -Eclipse Che workspace runtimes are powered by one or more Docker containers. When a user creates a workpace, they do so from a [stack]() which includes a Dockerfile or reference to a Docker image which will be used to create the containers for the workspace runtimes. Che stacks can pull that image from a public registry, like DockerHub, or a private registry. Images in a registry can be publicly visible or private, which require user credentials to access. You can also set up a private registry to act as a mirror to Docker Hub. And, if you are running Eclipse Che behind a proxy, you can configure the Docker daemon registry to operate behind a proxy. - -### Private Images -When users create a workspace in Eclipse Che, they must select a Docker image to power the workspace. We provide ready-to-go stacks which reference images hosted at the public Docker Hub, which do not require any authenticated access to pull. You can provide your own images that are stored in a local private registry or at Docker Hub. The images may be publicly or privately visible, even if they are part of a private registry. - -If your stack images that Che wants to pull require authenticated access to any registry, or if you want Che to push snapshot images into a registry (also requiring authenticated access), then you must configure registry authentication. - -In `che.env`: -``` -CHE_DOCKER_REGISTRY_AUTH_REGISTRY1_URL=url1 -CHE_DOCKER_REGISTRY_AUTH_REGISTRY1_USERNAME=username1 -CHE_DOCKER_REGISTRY_AUTH_REGISTRY1_PASSWORD=password1 - -CHE_DOCKER_REGISTRY_AWS_REGISTRY1_ID=id1 -CHE_DOCKER_REGISTRY_AWS_REGISTRY1_REGION=region1 -CHE_DOCKER_REGISTRY_AWS_REGISTRY1_ACCESS__KEY__ID=key_id1 -CHE_DOCKER_REGISTRY_AWS_REGISTRY1_SECRET__ACCESS__KEY=secret1 -``` - -There are different configurations for AWS EC2 and the Docker regsitry. You can define as many different registries as you'd like, using the numerical indicator in the environment variable. In case of adding several registries just copy set of properties and append `REGISTRY[n]` for each variable. - - -#### Pulling Private Images in Stacks -Once you have configured private registry access, any Che stack that has a `FROM /` that requires authenticated access will use the provided credentials within `che.env` to access the registry. - -```text -# Syntax -FROM /: - -# Example: -FROM my.registry.url:9000/image:latest -``` - -### Using Snapshots with Private Registries -You can configure Che to save your workspace snapshots to a private registry that you have installed, such as JFrog's Artifactory or Docker's Enterprise Registry. The default configuration of workspace snapshots is to save to local disk. - -#### Save Workspace Snapshots in a Private Registry -The default configuration for workspace snapshots is to have them written to disk as TAR files. This is faster, but not centralized. You can have workspace snapshots saved in a private registry. In `che.env`: - -``` -CHE_DOCKER_REGISTRY__FOR__SNAPSHOTS=true -CHE_DOCKER_REGISTRY= -``` - -### Custom Dockerfiles and Composefiles for Workspaces -Within Che, your workspaces are powered by a set of runtime environments. The default runtime is Docker. Typically, admins have pre-built images in DockerHub or another registry which are pulled when the workspace is created. You can optionally provide custom Dockerfiles (or let your users provide their own Dockerfiles), which will dynamically create a workspace image when a user creates a new workspace. - -To use your custom Dockerfiles, you can: - -1. Create a [custom stack](), which includes a [recipe]() with your Dockerfile. -2. Or, users can create a custom recipe when creating a workspace that references your registry. - -### Privileged Mode -Docker's privileged mode allows a container to have root-level access to the host from within the container. This enables containers to do more than they normally would, but opens up security risks. You can enable your workspaces to have privileged mode, giving your users root-level access to the host where Che is running (in addition to root access of their workspace). Privileged mode is necessary if you want to enable certain features such as Docker in Docker. - -By default, Che workspaces powered by a Docker container are not configured with Docker privileged mode. There are many security risks to activating this feature - please review the various issues with blogs posted online. - -```shell -# Update your che.env: -CHE_DOCKER_PRIVILEGED_MODE=true -``` - -### Mirroring Docker Hub -If you are running a private registry internally to your company, you can [optionally mirror Docker Hub](https://docs.docker.com/registry/mirror/). Your private registry will download and cache any images that your users reference from the public Docker Hub. You need to [configure your Docker daemon to make use of mirroring](https://docs.docker.com/registry/mirror/). - -### Using Docker In Workspaces -If you'd like your users to work with projects which have their own Docker images and Docker build capabilities inside of their workspace, then you need to configure the workspace to work with Docker. You have two options: - -1. Activate Docker's prvileged mode, where your user workspaces have access to the host. -2. Configure Che to setup workspaces to volume mount your host Daemon - -These two tactics will allow user workspaces to perform `docker` commands from within their workspace to create and work with Docker containers that will be outside the workspace. In other words, this makes your user's workspace feel like their laptop where they would normally be performing `docker build` and `docker run` commands. - -You will need to make sure that your user's workspaces are powered from a stack that has Docker installed inside of it. Che's default images do not have Docker installed, but we have sample stacks (see the Che in Che stack). - - -# Networking -Eclipse Che makes connections between three entities: the browser, the Che server running in a Docker container, and a workspace running in a Docker container. - -If you distribute these components onto different nodes, hosts or IP addresses, then you may need to add additional configuration parameters to bridge different networks. - -Also, since the Che server and your Che workspaces are within containers governed by a Docker daemon, you also need to ensure that these components have good bridges to communicate with the daemon. - -Generally, if your browser, Che server and Che workspace are all on the same node, then `localhost` configuration will always work. - -### WebSockets -Che relies on web sockets to stream content between workspaces and the browser. We have found many networks and firewalls to block portions of Web socket communications. If there are any initial configuration issues that arise, this is a likely cause of the problem. - -### Topology -The Che server runs in its own Docker container, "Che Docker Container", and each workspace gets an embedded runtime which can be a set of additional Docker containers, "Docker Container(n)". All containers are managed by a common Docker daemon, "docker-ip", making them siblings of each other. This includes the Che server and its workspaces - each workspace runtime environment has a set of containers that is a sibling to the Che server, not a child. - -TODO: UPDATE WITH ACCURANTE IMAGE -![Capture_.PNG]({{ base }}/assets/imgs/Capture_.PNG) - -### Connectivity -The browser client initiates communication with the Che server by connecting to `che-ip`. This IP address must be accessible by your browser clients. Internally, Che runs on Tomcat which is bound to port `8080`. This port can be altered by setting `CHE_PORT` during start or in your `che.env`.\ - -When a user creates a workspace, the Che server connects to the Docker daemon at `docker-ip` and uses the daemon to launch a new set of containers that will power the workspace. These workspace containers will have a Docker-configured IP address, `workspace-ip`. The `workspace-ip` must also be reachable by your browser host. - -Che goes through a progression algorithm to establish the protocol, IP address and port to establish communications when it is booting or starting a workspace. You can override certain parameters in Che's configuration to overcome issues with the Docker daemon, workspaces, or browsers being on different networks. - -### Docker Connectivity -There are multiple techniques for connecting to Docker including Unix sockets, localhost, and remote connections over TCP protocol. Depending upon the type of connection you require and the location of the machine node running Docker, we use different parameters. - -TODO: LINK TO DOCKER DOCS ON SETTING TCP VS UNIX FOR A DAEMON - -### Workspace Port Exposure -Inside your user's workspace containers, Che launches microservices on port `4401` and `4403`. We also launch SSH agents on port `22`. The bash terminal accessible in the workspace is also launched as an agent in the workspace on port `4411`. Custom stacks (configured in the dashboard) may expose additional services on different ports. - -Docker uses ephemeral port mapping. The ports accessible to your clients start at port `32768` and go through a wide range. When we start services internal to Docker, they are mapped to one of these ports. It is these ports that the browser (or SSH) clients connect to, and would need to be opened if connecting through a firewall. - -Additionally, if services are started within the workspace that expose their own ports, then those ports need to have an `EXPOSE ` command added to the workspace image Dockerfile, or from within the user dashboard these ports need to be explicitly added to the workspace configuration. As a courtesy, in our default stack images, we expose port `80` and `8080` within the container for any users that want to launch services on those ports. - -### Firewalls -On Linux, a firewall may block inbound connections from within Docker containers to your localhost network. As a result, the workspace agent is unable to ping the Che server. You can check for the firewall and then disable it. - -Firewalls will typically cause traffic problems to appear when you are starting a new workspace. There are certain network configurations where we direct networking traffic between workspaces and Che through external IP addresses, which can flow through routers or firewalls. If ports or protocols are blocked, then certain functions will be unavailable. - -#### Running Behind a Firewall (Linux/Mac) -```shell -# Check to see if firewall is running: -systemctl status firewalld - -# Check for list of open ports -# Verify that ports 8080tcp, 7946tcp/udp, 32768-65535tcp are open -firewall-cmd --list-ports - -# Optionally open ports on your local firewall: -firewall-cmd --permanent --add-port=8080/tcp -... and so on - -# You can also verify that ports are open: -nmap -Pn -p localhost - -# If the port is closed, then you need to open it by editing /etc/pf.conf. -# For example, open port 1234 for TCP for all interfaces: -pass in proto tcp from any to any port 1234 - -# And then restart your firewall -``` - -#### Running Che Behind a Firewall (Windows) - -There are many third party firewall services. Different versions of Windows OS also have different firewall configurations. The built-in Windows firewall can be configured in the control panel under "System and Security": -1. In the left pane, right-click `Inbound Rules`, and then click `New Rule` in the action pane. -2. In the `Rule Type` dialog box, select `Port`, and then click `Next`. -3. In the `Protocol and Ports` dialog box, select `TCP`. -4. Select speicfic local ports, enter the port number to be opened and click `Next`. -5. In the `Action` dialog box, select `Allow the Connection`, and then click `Next`. -6. In the `Name` dialog box, type a name and description for this rule, and then click `Finish`. diff --git a/docs/_docs/setup/che-setup-docker.md b/docs/_docs/setup/che-setup-docker.md deleted file mode 100644 index 6b6713f4195..00000000000 --- a/docs/_docs/setup/che-setup-docker.md +++ /dev/null @@ -1,240 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Docker Installation -excerpt: "Run the Che server with Docker bypassing the CLI with workspaces mounted on your host." -layout: docs -permalink: /:categories/docker/ ---- -{% include base.html %} -You can run the Che server directly by launching a Docker image. This approach bypasses the CLI, which has additional utilities to simplify administration and operation. The `eclipse/che-server` Docker image is appropriate for running Che within clusters, orchestrators, or by third party tools with automation. - -# Run the Image -```shell -# Run the latest released version of Che -# Replace with any host folder -# Che will place backup files there - configurable properties, workspaces, lib, storage -docker run -p 8080:8080 \ - --name che \ - --rm \ - -v /var/run/docker.sock:/var/run/docker.sock \ - -v :/data \ - eclipse/che-server:5.0.0-latest - -# To run the nightly version of Che, replace eclipse/che-server:5.0.0-latest with -eclipse/che-server:nightly - -# To run a specific tagged version of Che, replace eclipse/che-server:5.0.0-latest with -eclipse/che-server: - -# Stop the container running Che -docker stop che - -# Restart the container running Che and restart the Che server -docker restart che - -# Upgrade to a newer version -docker pull eclipse/che-server:5.0.0-latest -docker restart che\ -``` -Che has started when you see `Server startup in ##### ms`. After starting, Che is available at `localhost:8080` or a remote IP if Che has been started remotely. The examples on this page assume that I am running this container on a Windows machine and I would like my workspaces to be saved in `C:\tmp`. Note that on Windows, volume mounts require Linux-formatted syntax, for which they are here. - -## SELinux -If you are on SELinux then run this instead: -```shell -# Run the latest released version of Che -docker run -p 8080:8080 \ - --name che \ - -v /var/run/docker.sock:/var/run/docker.sock \ - -v /C/tmp:/data:Z \ - eclipse/che-server:5.0.0-latest\ -``` -## Ports -Tomcat inside the container will bind itself to port 8080 by default. You must map this port to be exposed in your container using `-p 8080:8080`. If you want to change the port at which your browsers connect, then change the first value, such as `p 9000:8080`. This will route requests from port 9000 to the internal Tomcat bound to port 8080. If you want to change the internal port that Tomcat is bound, you must update the port binding and set `CHE_PORT` to the new value. -```text -docker run -p 9000:9500 \ - --name che \ - -e CHE_PORT=9500 \ - -v /var/run/docker.sock:/var/run/docker.sock \ - -v /C/tmp:/data \ - eclipse/che-server:5.0.0-latest\ -``` -## Configuration -Most important configuration properties are defined as environment variables that you pass into the container. You can also optionally pass in a custom `che.properties` which has internal Che configuration that is loaded when Che's tomcat is booted. For example, to have Che listen on port 9000: -```shell -docker run -p:9000:9000 \ - --name che \ - -e CHE_SERVER_ACTION=stop \ - -v /var/run/docker.sock:/var/run/docker.sock \ - -v /C/tmp:/data \ - eclipse/che-server:5.0.0-latest\ -``` -There are many variables that can be set. - -| Variable | Description | Defaults>>>>>>>>>>> -| --- | --- | --- -| `CHE_SERVER_ACTION` | The command to send to Tomcat. it can be [run | start | stop]. | `run` -| `CHE_LOCAL_CONF_DIR` | Folder where a custom `che.properties` located. If not provided, then the container will copy the system `che.properties` into `/data/conf/che.properties`. You can reuse this or replace it with configuration on a different folder using this variable. If you use this variable, you must also mount the same directory. | `/data/conf` -| `CHE_ASSEMBLY` | The path to a Che assembly that is on your host to be used instead of the assembly packaged within the `che-server` image. If you set this variable, you must also volume mount the same directory to `/home/user/che` | `/home/user/che` -| `CHE_IN_VM` | Set to 'true' if this container is running inside of a VM providing Docker such as boot2docker, Docker for Mac, or Docker for Windows. We auto-detect this for most situations, but it's not always perfect. | auto-detection -| `CHE_LOG_LEVEL` | Logging level of output for Che server. Can be `debug` or `info`. | `info` -| `CHE_IP` | IP address Che server will bind to. Used by browsers to contact workspaces. You must set this IP address if you want to bind the Che server to an external IP address that is not the same as Docker's. | The IP address set to the Docker host. This does cover 99% of situations, but on rare occassions we are not able to discover this IP address and you must provide it. -| `CHE_DEBUG_SERVER` | If `true`, then will launch the Che server with JPDA activated so that you a Java debugger can attach to the Che server for debugging plugins, extensions, and core libraries. | `false` -| `CHE_DEBUG_SERVER_PORT` | The port that the JPDA debugger will listen. | `8000` -| `CHE_DEBUG_SERVER_SUSPEND` | If `true`, then activates `JPDA_SUSPEND` flag for Tomcat running the Che server. Used for advanced internal debugging of extensions. | `false` -| `CHE_PORT` | The port the Che server will bind itself to within the Che container. | '8080` - -## Run Che on Public IP Address -If you want to have remote browser clients connect to the Che server (as opposed to local browser clients) and override the defaults that we detect, set `CHE_IP` to the Docker host IP address that will have requests forwarded to the `che-server` container. - -We run an auto-detection algorithm within the che-server container to determine this IP. If Docker is running on `boot2docker` this is usually the `eth1` interface. If you are running Docker for Windows or Docker for Mac this is usually the `eth0` interface. If you are running Docker natively on Linux, this is the `docker0` interface. If your host that is running Docker has its IP at 10.0.75.4 and you wanted to allow remote clients access to this container then: -```shell -docker run -p:8080:8080 \ - --name che \ - -e CHE_IP=10.0.75.4 \ - -v /var/run/docker.sock:/var/run/docker.sock \ - -v /C/tmp:/data \ - eclipse/che-server:5.0.0-latest\ -``` -## Run Che as a Daemon -Pass the `--restart always` parameter to the docker syntax to have the Docker daemon restart the container on any exit event, including when your host is initially booting. You can also run Che in the background with the `-d` option. -```shell -docker run -p:8080:8080 \ - --name che \ - --restart always \ - -e CHE_IP=10.0.75.4 \ - -v /var/run/docker.sock:/var/run/docker.sock \ - -v /C/tmp:/data \ - eclipse/che-server:5.0.0-latest\ -``` -## Override Che Internals -Eclipse Che running in the container has its configuration in `/data/conf/che.properties`. This file is copied into the directory that you mount into `/data`. You can modify this file and restart Che if you want. - -You can also start a shell session in the context of the running container. This will allow you to browse all directories and use your favorite text editor. - -```shell -sudo docker exec -it che /bin/bash - -# You can also just edit /home/user/che/conf/che.properties`: -sudo docker exec -it che vi /data/conf/che.properties - -# After you finish making changes, restart the contain -docker restart che\ -``` -You can save your Che configuration to reside outside of the container to be reusable between different container instances. Create a local `che.properties` file, volume mount it into the container, and also tell Che in the container where to locate this file. -```shell -# Mount host directory with che.properties into container and inform Che where it is. -# Place the folder with che.properties as a mount to /conf -docker run -p:8080:8080 \ - --name che \ - --restart always \ - -e CHE_IP=10.0.75.4 \ - -v /var/run/docker.sock:/var/run/docker.sock \ - -v /C/tmp:/data \ - - -v /C/conf:/conf \ - - eclipse/che-server:5.0.0-latest\ -``` -## Use Local Che Assembly -You can run the Che image with a Che assembly that you have installed (or compiled) locally on your host. If you are developing a custom assembly, extension, or developing Che, you can mount your local binaries built on your host into the container by mounting the assembly to `/assembly`. -```text -# If your local assembly is located at /home/my_assembly: -docker run -p:8080:8080 \ - --name che \ - --restart always \ - -v /var/run/docker.sock:/var/run/docker.sock \ - -v /C/tmp:/data \ - -v /C/conf:/conf \ - - -v /home/my_assembly:/assembly \ - - eclipse/che-server:5.0.0-latest\ -``` -## Port Exposure -Docker uses the ephemeral port range from `32768-65535`. If you do not want to expose ports `32768-65535` because of the large port range, you need to reconfigure your Docker daemon to communicate over the `docker0` interface. You need to set `DOCKER_MACHINE_HOST` to `172.17.0.1` and modify `machine.docker.che_api.endpoint` in the `che.properties` file. -```shell -# Modify your local che.properties with: -machine.docker.che_api.endpoint=http://172.17.0.1:8080/wsmaster/api - -# Run the Che container with: -docker run -p:8080:8080 \ - --name che \ - --restart always \ - -v /var/run/docker.sock:/var/run/docker.sock \ - -v /C/tmp:/data \ - -v /C/conf:/conf \ - -v /home/my_assembly:/assembly \ - - -e DOCKER_MACHINE_HOST=172.17.0.1 \ - - eclipse/che-server:5.0.0-latest\ -``` - -```yaml -che: - image: eclipse/che-server:5.0.0-latest - port: 8080:8080 - restart: always - environment: - CHE_LOCAL_CONF_DIR=/C/conf - CHE_ASSEMBLY=/home/my_assembly - DOCKER_MACHINE_HOST=172.17.0.1 - volumes: - - /var/run/docker.sock:/var/run/docker.sock - - /C/tmp:/data - - /C/conf:/conf - - /home/my_assembly:/assembly - container_name: che\ -``` -Save this into a file named `Composefile`. Replace the `${IP}` with the IP address of the server where you are hosting Eclipse Che. You can then run this with Docker Compose with `docker-compose -f Composefile -d`. -# Docker Unix Socket Mounting vs TCP Mode -The `-v /var/run/docker.sock:/var/run/docker.sock` syntax is for mounting a Unix socket so that when a process inside the container speaks to a Docker daemon, the process is redirected to the same socket on the host system. - -However, peculiarities of file systems and permissions may make it impossible to invoke Docker processes from inside a container. If this happens, the Che startup scripts will print an error about not being able to reach the Docker daemon with guidance on how to resolve the issue. - -An alternative solution is to run Docker daemon in TCP mode on the host and export `DOCKER_HOST` environment variable in the container. You can tell the Docker daemon to listen on both Unix sockets and TCP. On the host running the Docker daemon: -```text -# Set this environment variable and restart the Docker daemon -DOCKER_OPTS=" -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock" - -# Verify that the Docker API is responding at: -http://localhost:2375/containers/json -``` -Having verified that your Docker daemon is listening, run the Che container with the with `DOCKER_HOST` environment variable set to the IP address of `docker0` or `eth0` network interface. If `docker0` is running on 1.1.1.1 then: -```shell -docker run -p:8080:8080 \ - --name che \ - --restart always \ - -v /var/run/docker.sock:/var/run/docker.sock \ - -v /C/tmp:/data \ - -v /C/conf:/conf \ - -v /home/my_assembly:/assembly \ - -e DOCKER_MACHINE_HOST=172.17.0.1 \ - - -e DOCKER_HOST=tcp://1.1.1.1:2375 \ - - eclipse/che-server:5.0.0-latest\ -``` - -# Where Is Data Stored? -The Che container uses host mounted volumes to store persistent data: - -| Local Location | Container Location | Usage -| --- | --- | --- -| `/var/run/docker.sock` | `/var/run/docker.sock` | This is how Che gets access to Docker daemon. This instructs the container to use your local Docker daemon when Che wants to create its own containers. -| `//lib` | `/data/lib` | Inside the container, we make a copy of important libraries that your workspaces will need and place them into `/lib`. When Che creates a workspace container, that container will be using your local Docker daemon and the Che workspace will look for these libraries in your local `/lib`. This is a tactic we use to get files from inside the container out onto your local host. -| `//workspaces` | `/data/workspaces` | The location of your workspace and project files. -| `//storage` | /data/storage` | The location where Che stores the meta information that describes the various workspaces, projects and user preferences. - - -# Debugging -Inside the Che container is a Tomcat service. The Tomcat debugger is running on port 8000. If you want to connect to that port, you need to bind it as part of the docker run command. -```shell -docker run -p 8080:8080 \ - -p 9000:8000 \ - --name che \ - --restart always \ - -v /var/run/docker.sock:/var/run/docker.sock \ - -v /C/tmp/:/data \ - eclipse/che-server:5.0.0-latest\ -``` diff --git a/docs/_docs/setup/che-setup-getting-started-saas-cloud.md b/docs/_docs/setup/che-setup-getting-started-saas-cloud.md deleted file mode 100644 index 13e0d34b882..00000000000 --- a/docs/_docs/setup/che-setup-getting-started-saas-cloud.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Getting Started: SaaS Cloud -excerpt: "" -layout: docs -permalink: /:categories/getting-started-saas-cloud/ ---- -{% include base.html %} -You can use Eclipse Che workspaces hosted at http://codenvy.com by signing up for a free account and accepting Codenvy's terms of service. -# How to Get Help -**Support:** If the unthinkable happens, or you have a question, you can post [issues on our GitHub page](https://github.com/eclipse/che/issues). Please follow the [guidelines on issue reporting](https://github.com/eclipse/che/blob/master/CONTRIBUTING.md). - -**Documentation:** We put a lot of effort into our docs. Please add suggestions on areas for improvement. -# 1. Get a Codenvy SaaS Account -Eclipse Che is offered as hosted SaaS at Codenvy.com. See our [Eclipse Che site](https://www.eclipse.org/che/getting-started/cloud/) to get setup. -# 2. Develop with Che -Now that you have access to Che at codenvy.com there are a lot of fun things to try: -- Become familiar with Che through [one of our tutorials](https://eclipse-che.readme.io/docs/get-started-with-java-and-che). -- [Import a project](https://eclipse-che.readme.io/docs/import-a-project) from git. -- Use [commands](https://eclipse-che.readme.io/docs/commands) to build and run a project. -- Create a [preview URL](https://eclipse-che.readme.io/docs/previews) to share your app. -- Setup a [debugger](https://eclipse-che.readme.io/docs/debug). -- Experiment with [chedir](https://dash.readme.io/project/eclipse-che/docs/getting-started-chedir). -- Create a [custom stack](https://eclipse-che.readme.io/docs/stacks). diff --git a/docs/_docs/setup/che-setup-getting-started.md b/docs/_docs/setup/che-setup-getting-started.md deleted file mode 100644 index 85d924303b2..00000000000 --- a/docs/_docs/setup/che-setup-getting-started.md +++ /dev/null @@ -1,272 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Getting Started: Local -excerpt: "" -layout: docs -permalink: /:categories/getting-started/ ---- -{% include base.html %} -Eclipse Che is a developer workspace server and cloud IDE. You install, run, and manage Eclipse Che with Docker. - -### Download -This is the administration guide for the on-premises installation of Eclipse Che. This document discusses the installation, configuration, and operation of Che that you host on your own hardware or IaaS provider. - -You can get a hosted version of Eclipse Che with Codenvy at [codenvy.io](http://codenvy.io). - -# How to Get Help -### Support: -If the unthinkable happens, or you have a question, you can post [issues on our GitHub page](https://github.com/eclipse/che/issues). Please follow the [guidelines on issue reporting](https://github.com/eclipse/che/blob/master/CONTRIBUTING.md) and provide: -* your OS distribution and version -- output of `docker version` command -- output of `docker info` command -- the full `docker run ...` syntax you used on the command line -- the output of `cli.log` - -### Documentation: -We put a lot of effort into our docs. Please add [suggestions on areas for improvement]() with a pull request. - -# Quick Start -On any computer with Docker 1.11+ installed: -```shell -# Interactive help -docker run -it eclipse/che-cli start - -# Or, full start syntax where is a local directory -docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v :/data eclipse/che-cli start -``` - -# Operate Che -```shell -# Start Eclipse Che with user data saved on Windows in c:\tmp -docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v /c/tmp:/data eclipse/che-cli start -INFO: (che cli): Loading cli... -INFO: (che cli): Checking registry for version 'nightly' images -INFO: (che config): Generating che configuration... -INFO: (che config): Customizing docker-compose for running in a container -INFO: (che start): Preflight checks - port 8080 (http): [AVAILABLE] - -INFO: (che start): Starting containers... -INFO: (che start): Services booting... -INFO: (che start): Server logs at "docker logs -f che" -INFO: (che start): Booted and reachable -INFO: (che start): Ver: nightly -INFO: (che start): Use: http://:8080 -INFO: (che start): API: http://:8080/swagger - -# Stop Che -docker run eclipse/che-cli stop - -# Restart Che -docker run eclipse/che-cli restart - -# Run a specific version of Che -docker run eclipse/che-cli: start - -# Get help -docker run eclipse/che-cli - -# If boot2docker on Windows (rare), mount a subdir of `%userprofile%` to `:/data`. For example: -docker run -v /c/Users/tyler/che:/data eclipse/che-cli start - -# If Che will be accessed from other machines add your server's external IP -docker run -e CHE_HOST= eclipse/che-cli start -``` - -# Develop with Che -Now that Che is running there are a lot of fun things to try: -- Become familiar with Che through [one of our tutorials](). -- [Import a project](https://eclipse-che.readme.io/docs/import-a-project) and setup [git authentication](). -- Use [commands]() to build and run a project. -- Create a [preview URL]() to share your app. -- Setup a [debugger](). -- Create reproducible workspaces with [chedir](). -- Create a [custom runtime stack](https://eclipse-che.readme.io/docs/stacks). - -# Syntax -``` -USAGE: - docker run -it --rm eclipse/che-cli: [COMMAND] - -MANDATORY DOCKER PARAMETERS: - -v :/data Where user, instance, and log data saved - -OPTIONAL DOCKER PARAMETERS: - -e CHE_HOST= IP address or hostname where che will serve its users - -e CHE_PORT= Port where che will bind itself to - -v :/data/instance Where instance, user, log data will be saved - -v :/data/backup Where backup files will be saved - -v :/repo che git repo to activate dev mode - -v :/sync Where remote ws files will be copied with sync command - -v :/unison Where unison profile for optimzing sync command resides - -COMMANDS: - action Start action on che instance - backup Backups che configuration and data to /data/backup volume mount - config Generates a che config from vars; run on any start / restart - destroy Stops services, and deletes che instance data - download Pulls Docker images for the current che version - help This message - info Displays info about che and the CLI - init Initializes a directory with a che install - offline Saves che Docker images into TAR files for offline install - restart Restart che services - restore Restores che configuration and data from /data/backup mount - rmi Removes the Docker images for , forcing a repull - ssh [machine-name] SSH to a workspace if SSH agent enabled - start Starts che services - stop Stops che services - sync Synchronize workspace with current working directory - test Start test on che instance - upgrade Upgrades che from one version to another with migrations and backups - version Installed version and upgrade paths -``` - -# Pre-Reqs -### Hardware: -* 1 cores -* 256MB RAM -* 300MB disk space - -Che requires 300 MB storage and 256MB RAM for internal services. The RAM, CPU and storage resources required for your users' workspaces are additive. Che Docker images consume ~300MB of disk and the Docker images for your workspace templates can each range from 5MB up to 1.5GB. Che and its dependent core containers will consume about 500MB of RAM, and your running workspaces will each require at least 250MB RAM, depending upon user requirements and complexity of the workspace code and intellisense. - -Boot2Docker, docker-machine, Docker for Windows, and Docker for Mac are all Docker variations that launch VMs with Docker running in the VM with access to Docker from your host. We recommend increasing your default VM size to at least 4GB. Each of these technologies have different ways to allow host folder mounting into the VM. Please enable this for your OS so that Che data is persisted on your host disk. - -### Software: -* Docker 1.11+ - -The Che CLI - a Docker image - manages the other Docker images and supporting utilities that Che uses during its configuration or operations phases. The CLI also provides utilities for downloading an offline bundle to run Che while disconnected from the network. - -Given the nature of the development and release cycle it is important that you have the latest version of Docker installed because any issue that you encounter might have already been fixed with a newer Docker release. - -Install the most recent version of the Docker Engine for your platform using the [official Docker releases](http://docs.docker.com/engine/installation/), including support for Mac and Windows! If you are on Linux, you can also install using: -```bash -wget -qO- https://get.docker.com/ | sh -``` - -Verify that Docker is installed with: -```shell -# Should print "Hello from Docker!" -docker run hello-world -``` - -Sometimes Fedora and RHEL/CentOS users will encounter issues with SElinux. Try disabling selinux with `setenforce 0` and check if resolves the issue. If using the latest docker version and/or disabling selinux does not fix the issue then please file a issue request on the [issues](https://github.com/eclipse/che/issues) page. - -#### Ports -The default port required to run Che is `8080`. Che performs a preflight check when it boots to verify that the port is available. You can pass `-e CHE_PORT=` in Docker portion of the start command to change the port that Che starts on. - -#### Internet Connection -You can install Che while connected to a network or offline, disconnected from the Internet. If you perform an offline intallation, you need to first download a Che assembly while in a DMZ with a network connection to DockerHub. - -# Versions -Each version of Che is available as a Docker image tagged with a label that matches the version, such as `eclipse/che-cli:5.0.0-M7`. You can see all versions available by running `docker run eclipse/che-cli version` or by [browsing DockerHub](https://hub.docker.com/r/eclipse/che-cli/tags/). - -We maintain "redirection" labels which reference special versions of Che: - -| Variable | Description | -|----------|-------------| -| `latest` | The most recent stable release. | -| `5.0.0-latest` | The most recent stable release on the 5.x branch. | -| `nightly` | The nightly build. | - -The software referenced by these labels can change over time. Since Docker will cache images locally, the `eclipse/che-cli:` image that you are running locally may not be current with the one cached on DockerHub. Additionally, the `eclipse/che-cli:` image that you are running references a manifest of Docker images that Che depends upon, which can also change if you are using these special redirection tags. - -In the case of 'latest' images, when you initialize an installation using the CLI, we encode a `/instance/che.ver` file with the numbered version that latest references. If you begin using a CLI version that mismatches what was installed, you will be presented with an error. - -To avoid issues that can appear from using 'nightly' or 'latest' redirections, you may: -1. Verify that you have the most recent version with `docker pull eclipse/che-cli:`. -2. When running the CLI, commands that use other Docker images have an optional `--pull` and `--force` command line option [which will instruct the CLI to check DockerHub]() for a newer version and pull it down. Using these flags will slow down performance, but ensures that your local cache is current. - -If you are running Che using a tagged version that is a not a redirection label, such as `5.0.0-M7`, then these caching issues will not happen, as the software installed is tagged and specific to that particular version, never changing over time. - -# Volume Mounts -We use volume mounts to configure certain parts of Che. The presence or absence of certain volume mounts will trigger certain behaviors in the system. For example, you can volume mount a Che source git repository with `:/repo` to activate development mode where we start Che's containers using source code from the repository instead of the software inside of the default containers. - -At a minimum, you must volume mount a local path to `:/data`, which will be the location that Che installs its configuration, user data, version and log information. Che also leaves behind a `cli.log` file in this location to debug any odd behaviors while running the system. In this folder we also create a `che.env` file which contains all of the admin configuration that you can set or override in a single location. - -You can also use volume mounts to override the location of where your user or backup data is stored. By default, these folders will be created as sub-folders of the location that you mount to `:/data`. However, if you do not want your `/instance`, and `/backup` folder to be children, you can set them individually with separate overrides. - -``` -docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock - -v :/data - -v :/data/instance - -v :/data/backup - eclipse/che-cli: [COMMAND] - -``` - -# Hosting -If you are hosting Che at a cloud service like DigitalOcean, `CHE_HOST` must be set to the server's IP address or its DNS. - -We will attempt to auto-set `CHE_HOST` by running an internal utility `docker run --net=host eclipse/che-ip:nightly`. This approach is not fool-proof. This utility is usually accurate on desktops, but usually fails on hosted servers. You can explicitly set this value to the IP address of your server: -``` -docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock - -v :/data - -e CHE_HOST= - eclipse/che-cli: [COMMAND] -``` - -# Proxy Installation -You can install and operate Che behind a proxy: -1. Configure each physical node's Docker daemon with proxy access. -2. Optionally, override workspace proxy settings for users if you want to restrict their Internet access. - -Before starting Che, configure [Docker's daemon for proxy access](https://docs.docker.com/engine/admin/systemd/#/http-proxy). If you have Docker for Windows or Docker for Mac installed on your desktop and installing Che, these utilities have a GUI in their settings which let you set the proxy settings directly. - -Please be mindful that your `HTTP_PROXY` and/or `HTTPS_PROXY` that you set in the Docker daemon must have a protocol and port number. Proxy configuration is quite finnicky, so please be mindful of providing a fully qualified proxy location. - -If you configure `HTTP_PROXY` or `HTTPS_PROXY` in your Docker daemon, we will add `localhost,127.0.0.1,CHE_HOST` to your `NO_PROXY` value where `CHE_HOST` is the DNS or IP address. We recommend that you add the short and long form DNS entry to your Docker's `NO_PROXY` setting if it is not already set. - -We will add some values to `che.env` that contain some proxy overrides. You can optionally modify these with overrides: -``` -CHE_HTTP_PROXY= -CHE_HTTPS_PROXY= -CHE_NO_PROXY=localhost,127.0.0.1, -CHE_HTTP_PROXY_FOR_WORKSPACES= -CHE_HTTPS_PROXY_FOR_WORKSPACES= -CHE_NO_PROXY_FOR_WORKSPACES=localhost,127.0.0.1, -``` - -The last three entries are injected into workspaces created by your users. This gives your users access to the Internet from within their workspaces. You can comment out these entries to disable access. However, if that access is turned off, then the default templates with source code will fail to be created in workspaces as those projects are cloned from GitHub.com. Your workspaces are still functional, we just prevent the template cloning. - -# Offline Installation -We support offline (disconnected from the Internet) installation and operation. This is helpful for restricted environments, regulated datacenters, or offshore installations. The offline installation downloads the CLI, core system images, and any stack images while you are within a network DMZ with DockerHub access. You can then move those files to a secure environment and start Che. - -### 1. Save Che Images -While connected to the Internet, download Che's Docker images: -```shell -docker run eclipse/che-cli: offline -``` -The CLI will download images and save them to `/backup/*.tar` with each image saved as its own file. You can save these files to a differnet location by volume mounting a local folder to `:/data/backup`. The version tag of the CLI Docker image will be used to determine which versions of dependent images to download. There is about 1GB of data that will be saved. - -The default execution will download none of the optional stack images, which are needed to launch workspaces of a particular type. There are a few dozen stacks for different programming languages and some of them are over 1GB in size. It is unlikely that your users will need all of the stacks, so you do not need to download all of them. You can get a list of available stack images by running `eclipse/che-cli offline --list`. You can download a specific stack by running `eclipse/che-cli offline --image:` and the `--image` flag can be repeatedly used on a single command line. - -### 2. Start Che In Offline Mode -Place the TAR files into a folder in the offline computer. If the files are in placed in a folder named `/tmp/offline`, you can run Che in offline mode with: - -```shell -# Load the CLI -docker load < /tmp/offline/eclipse_che-cli:.tar - -# Start Che in offline mode -docker run -v /tmp/offline:/data/backup eclipse/che-cli: start --offline -``` -The `--offline` parameter instructs the Che CLI to load all of the TAR files located in the folder mounted to `/data/backup`. These images will then be used instead of routing out to the Internet to check for DockerHub. The preboot sequence takes place before any CLI functions make use of Docker. The `eclipse/che-cli start`, `eclipse/che-cli download`, and `eclipse/che-cli init` commands support `--offline` mode which triggers this preboot seequence. - -# Uninstall -```shell -# Remove your Che configuration and destroy user projects and database -docker run eclipse/che-cli: destroy [--quiet|--cli] - -# Deletes Che's images from your Docker registry -docker run eclipse/che-cli: rmi - -# Delete the Che CLI -docker rmi -f eclipse/che-cli -``` - -# Licensing -Che is licensed with the Eclipse Public License. - -# Configuration -Change Che's port, hostname, oAuth, Docker, git, and networking by setting [Eclipse Che properties](). \ No newline at end of file diff --git a/docs/_docs/setup/che-setup-glossary.md b/docs/_docs/setup/che-setup-glossary.md deleted file mode 100644 index 2cba22644bf..00000000000 --- a/docs/_docs/setup/che-setup-glossary.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Glossary -excerpt: "" -layout: docs -permalink: /:categories/glossary/ ---- -{% include base.html %} -**Artifacts**: The packaged results of build processes executed by a command. Build artifacts are stored in your project tree, can be downloaded, or injected into other machines where they are used during process execution. - -**Command **: A configuration that defines a process that will execute within a machine. Commands can be used to launch builds, runs, unit tests or any process that is needed to execute against the files of a project. A command defines how a process will start and stop. Commands have scope and can be made reusable to different users depending upon where it is saved. Commands are injected into any machine controlled by Che, whether that machine is local or remote. - -**Compose Recipe**: A Docker syntax for defining the configuration and startup sequence of a set of containers. - -**Machine**: A virtual environment that contains a stack of software to be used when executing your project source code and artifacts. Project source code and build artifacts are stored within the machine and synchronized with your central project storage. A machine accepts commands that can start, modify or stop processes. A machine can be active (running) or suspended (saved snapshot) or destroyed (shutdown). The lifecycle of a machine such as booting or shutdown is triggered on various user events such as opening the IDE. Machines are granted an allocation of workspace resources for its execution. Machines can have type where different machines of the same type can be used interchangeably within the same project. Eclipse Che provides a native CLI and Docker implementation of Che server and machines. - -**Modules**: A module is a directory in a project that can be independently built and run. Modules have their own project type and attributes, which can affect how the command behavior works for that directory apart from others or the project as a whole. Modules can be nested. - -**Multi-Machine**: Much like a single machine definition but contains multiple machine definitions. Each machine within a virtual environment can accept commands that can start, modify or stop processes. A specially named "dev-machine" must be included with each virtual environment which contains the required dependencies/agents and project code. Each machine is granted an allocation of workspace resources for its own execution. Eclipse Che provides multiple machine through a compose recipe. - -**Permission**: An authorization granted to access resources. Permissions can be access permissions, which control specific access to resources such as file and project visibility. Permissions can also be behavior permissions, which control access to functionality in the system, such as rights to use the services of a plug-in. - -**Preview**: Preview objects are URLs that reference specific files or endpoints activated by your project when you run a command. For example, you may have a command to start a Spring application server and deploy your project's artifacts into the application server. A preview object can be used to present the user with the URL of the deployed application. - -**Private Workspace**: A workspace whose permissions are only available to an explicit set of users. - -**Process**: A result of a command. Processes run natively within a machine and are the result of either executing a terminal command or having a command injected into a machine. - -**Project**: A bundle of source code and configuration files. A project has access to facilities to edit, build, run and debug its contents. A project may be associated with a single source code repository. Projects have a type, which define default behaviors within the IDE and also affects the plug-ins that are injected into the machine that is powering the workspace hosting this project. Projects can reside in parent-child relationships, for which children projects are called modules. - -**Public Workspace**: A workspace whose configuration and runtime that can be accessed by anyone. - -**Recipe**: A definition or script that can be used to construct a machine. The default machine implementation within Che is Docker allowing Dockerfiles or Docker compose syntax to be use to define the recipe content. - -**Runtime**: Instances of machines that provide an environment for agents and projects to run within the workspace.​ - -**Resource**: Physical asset consumed by a workspace. Resources can be defined differently for each workspace. - -**Snapshot**: A machine Instance saved to disk with its state preserved. Snapshots of machines are saved as Docker images. Machines and snapshots are bound to Workspaces. - -**Stack**: A stack is the configuration of a runtime that can be used to power a workspace. Users choose the stack that powers a workspace within the user dashboard. Stacks have a recipe that defines how the container should be created and also meta data that defines the tags associated with the stack. - -**Template**: A template is a packaged set of sample code that is launched in the workspace when a user creates a new project. Users can select from a template while using the user dashboard. Templates have both sample code and a default set of commands associated with them. Templates are loaded based upon the type of stack selected. You can add your own templates to the default Che distribution. - -**User**: Anyone interacting with the system. diff --git a/docs/_docs/setup/che-setup-intro.md b/docs/_docs/setup/che-setup-intro.md deleted file mode 100644 index 3659c073f9c..00000000000 --- a/docs/_docs/setup/che-setup-intro.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Introduction -excerpt: "" -layout: docs -permalink: /:categories/intro/ ---- -{% include base.html %} -Eclipse Che provides: - -* Workspaces that include runtimes and IDEs -* RESTful workspace server -* A browser-based IDE -* Plug-ins for languages, framework, and tools -* An SDK for creating plug-ins and assemblies -# Getting Started -You can get started with Che by: -- [Installing it locally](doc:che-getting-started) -- [Creating a hosted SaaS account](doc:getting-started-saas-cloud) -- [Installing it in a cloud instance you control](doc:usage-bitnami) -# Workspace Model - -![Docker--CodenvyMeeting.png]({{ base }}/assets/imgs/Docker--CodenvyMeeting.png) -Che defines the workspace to be the project code files and all of their dependencies necessary to edit, build, run, and debug them. In our world, we treat the IDE and the development runtime as a dependency of the workspace. These items are embedded and included with the workspace, whereever it may run. This compares to classic workspace definitions which may include the project code, but require the developer to bind their IDE and use their laptop localhost to provide a runtime. - -Each workspace is isolated from one another and is responsible for managing the lifecycle of the components that are contained within it. -![Docker--CodenvyMeeting(1).png]({{ base }}/assets/imgs/Docker--CodenvyMeeting(1).png) -A workspace contains one or more runtimes. The default runtime within our workspaces are Docker containers, but these runtimes can be replaced with other types of "machines" that offer different characteristics. We, for example, provide an SSH machine type and will soon provide localhost machines. The advantage of Docker as the runtime type allows users to define the contents of their runtime using Dockerfiles, for which we can then dynamically construct workspace runtimes without the user having to learn a lot of complex Docker syntax. -![Docker--CodenvyMeeting(2).png]({{ base }}/assets/imgs/Docker--CodenvyMeeting(2).png) -A workspace can have 0..n projects, with each project mapping to 0..1 remote version control repositories such as git, subversion, or mercurial. Projects are mounted into the workspace, so that they are available both inside of the workspace and also available on long term storage. Each project has a "type", such as "maven", which when selected will activate a series of plugins that alter the behavior of the workspace to accommodate that project type. Projects can have different types and they can also have modules which are sub-portions of a project that have their own typing and behaviors. -![Docker--CodenvyMeeting(3).png]({{ base }}/assets/imgs/Docker--CodenvyMeeting(3).png) -Each workspace has its own private browser IDE hosted within it. The browser IDE provided by Che is packaged as JavaScript and CSS, but our IDE could be replaced with other IDEs. Since each workspace has its own server runtimes, each workspace can have a customized IDE with different plugins packaged within it. -![Docker--CodenvyMeeting(4).png]({{ base }}/assets/imgs/Docker--CodenvyMeeting(4).png) -By default, each workspace also configures its own SSH server. This allows remote clients and desktop IDEs to SSH mount into the workspace. By SSH mounting, you can let IDEs like IntelliJ or Eclipse work with the projects and runtimes contained within Che. -![Docker--CodenvyMeeting(5).png]({{ base }}/assets/imgs/Docker--CodenvyMeeting(5).png) -Workspaces are hosted in the Che server, which is a lightweight runtime for managing workspaces. A single Che server can manage large volumes of workspaces, which themselves may or may not be running on the same host. Since Che workspace runtimes have their own runtimes, each workspace can be running on the same host or another host, managed by a docker daemon. The Che server is also a Docker container by default, which itself could be operated by compose or Swarm. -![Docker--CodenvyMeeting(6).png]({{ base }}/assets/imgs/Docker--CodenvyMeeting(6).png) -Since the workspaces are servers that have their own runtimes, they are collaborative and shareable. This allows multiple users to access the same workspace at the same time. Each workspace has its own unique URL which allows multi-user access. We currently support multiple users within a single workspace on a last-write-wins policy. Before the end of 2016, we'll have multi-cursor editing using an operational transform. -![Docker--CodenvyMeeting(7).png]({{ base }}/assets/imgs/Docker--CodenvyMeeting(7).png) -Each workspace is defined with a JSON data model that contains the definition of its projects, its runtimes, its IDE, and other necessary information that allows a Che server to create replicas. This allows workspaces to move from one location to another, such as from one Che server to another Che server. You will never have the "but it runs on that computer" issue again. Workspaces can also have their internal state snapshot and saved in a registry, so replicas can be created from the original template, or from images that contain modifications made after a user started working with the workspace. -![Docker--CodenvyMeeting(8).png]({{ base }}/assets/imgs/Docker--CodenvyMeeting(8).png) -Both the Che server and each workspace have their own embedded RESTful APIs. Everything that is done by the user dashboard Web application and the browser IDE is done over RESTful APIs. You can access these APIs using swagger as Swagger configurations are provided within each service. The API set within the server and each workspace dynamically changes based upon the plugins that have been deployed by the admin or the user. -# Users -Che has three types of users: - * **Developers**. Che can be installed and used as a local IDE for any kind of programming language or framework, such as Java and JavaScript. While Che runs as a server, it can be run on a desktop, server, or within an embedded device. You can use Che with our embedded browser IDE or your existing IDE which is allowed to SSH into the Che workspaces. - - * **Product Owners**. Che provides APIs hosted within its workspace server to manage environments, workspaces, projects, templates, stacks, and intellisense for developer activities such as editing, syntax analysis, compiling, packaging, and debugging. You can use Che to host on-demand workspaces accessed by the Che IDE or a client that your product team authors. For example, SAP uses the Che workspace server to embed its development tools for SAP Hana. - - * **Plug-in Providers**. Che provides a SDK to create and package plug-ins that modify the browser IDE, workspaces, or the Che server. ISVs and tool providers can add new project types, programming languages, tooling extensions, or applications. Che plug-ins can be authored for the client-side IDE or the server-side. - -Che is supported by engineers from Bitnami, Codenvy, SAP, IBM, Serli, Red Hat, Tomitribe,and WSO2. [Codenvy](http://codenvy.com) provides a multi-tenant, multi-user infrastructure for Che with enhanced security and deployable on any public or private cloud. -# Logical Architecture - -![Capture_.PNG]({{ base }}/assets/imgs/Capture_.PNG) -Che is a workspace server that runs on top of an application server like Tomcat. When the Che server is launched, the IDE is loaded as a Web application accessible via a browser at `http://localhost:8080/`. The browser downloads the IDE as a single page web app from the Che server. The Web application provides UI components such as wizards, panels, editors, menus, toolbars, and dialog boxes. - -As a user interacts with the Web application, they will create workspaces, projects, environments, machines, and other artifacts necessary to code and debug a project. The IDE communicates with Che over RESTful APIs that manage and interact with a Workspace Master. - -The Che server controls the lifecycle of workspaces. Workspaces are isolated spaces where developers can work. Che injects various services into each workspace, including the projects, source code, Che plug-ins, SSH daemon, and language services such as JDT core Intellisense to provide refactoring for Java language projects. The workspace also contains a synchronizer which, depending upon whether the workspace is running locally or remotely, is responsible for synchronizing project files from within the machine with Che long term storage. -![Capture2_.PNG]({{ base }}/assets/imgs/Capture2_.PNG) -Che defines the notion of a workspace as the combination of projects, environments, and commands. A project is the fundamental unit of code available as a set of folders, files, and modules. A project may be mapped 1:1 to an external git or subversion repository from which it is cloned. A workspace may have zero or more projects. Projects have a project type which, depending upon the type selected, causes Che to enable the workspace with different behaviors. For example, a maven project type causes Che to install the maven and Java plug-ins into the workspace. - -A machine is a runtime unit that provides a stack of software and a set of resources to run the projects of the workspace. The machine is bound to the workspace and to the projects. Che synchronizes the project files within the machine. A machine is defined by a recipe that contains the list of software that should be executing within the machine. The default machine implementation in Che is Docker and we use Dockerfiles to define the recipes for different types of runtimes. We also have a concept called, "stacks" which are pre-defined recipes with additional meta-information. Che provides default recipes and stacks, but users can define their own. The machine's lifecycle is managed by each Che workspace. As the workspace is booted, so is its underlying runtimes. Additionally, Che can install additional software into the machine to enable developer services such as Intellisense. For example, if the Java plug-in is activated because of the project type, Che installs an agent inside of the machine that runs JDT services that are then accessible by the projects synchronized onto the machine. -# Extensibility -Che provides an SDK for authoring new extensions, packaging extensions into plug-ins, and grouping plug-ins into an assembly. An assembly can either be executed stand alone as a new server, or, it can be installed onto desktops as an application using included installers. -![Extensibility.PNG]({{ base }}/assets/imgs/Extensibility.PNG) -There are a number of aspects that can be modified within Che. - -| Type | Description -| --- | --- -| IDE Extension | Modify the look-and-feel, panels, editors, wizards, menus, toolbars, and pop-up boxes of the client. IDE extensions are authored in Java and transpiled into a JavaScript Web application that is hosted on the Che server as a WAR file. -| Che Server Extension\n(aka, Worskspace Master) | Add or modify the core APIs that run within the Che server for managing workspaces, environments and machines. Workspace extensions are authored in Java and packaged as JAR files. -| Workspace Extension\n(aka, Workspace Agent) | Create or modify project-specific extensions that run within a workspace machine and have local access to project files. Define machine behaviors, code templates, command instructions, scaffolding commands, and intellisense. The Che Java extension is authored as a workspace agent extension, deployed into the machine, and runs JDT core services from Eclipse to do local intellisense operations against the remote workspace. - -Each extension type is packaged separately because they are deployed differently into the assembly. IDE extensions are transpiled using GWT to generate a cross-browser JavaScript. This application is packaged as a WAR file and hosted on the Che server. - -Workspace master extensions are deployed as services within the Che server. Once deployed, they activate new management services that can control users, identity and workspaces. - -Workspace agent extensions are compiled with Che core libraries and also deployed within an embedded Che server that runs inside of each workspace machine. The Che server is injected into machines created and controlled by the central workspace master Che server. This embedded server hosts your workspace agent extensions and provides a communication bridge between the services hosted within Che and the machines that are hosting the project. - -## Machines -When you develop with a desktop IDE, the workspace uses localhost as the execution environment for processes like build, run and debug. In a cloud IDE, localhost is not available, so the workspace server must generate the environments that it needs. These environments must be isolated from one another and scalable. We use Docker to generate containers that contain the software needed for each environment. Each workspace is given at least one environment, but users may create additional environments for each workspace if they want. Each container can have different software installed. Che installs different software into the machine based upon the project type. For example, a Java project will have the JDK, Git, and Maven installed. When a user is working within their Workspace, this container is booted by Che and the source code of the project is mounted within it. Developer actions like auto-complete and `mvn clean install` are processes that are executed within the container. Users can provide their own Dockerfiles that Che will build into images and extension developers can register Dockerfile templates associated with a project type. This allows Che to manage a potentially infinite number of environments while still giving users customization flexibility. - -# What's Included -Che ships with a large number of plug-ins for many programming languages, build systems, source code tools, and infrastructure including Java, Maven, Ant, Git, Subversion, JavaScript, and Angular.JS. The community is developing their own and many are merged into the main Che repository. Che can be installed on any operating system that supports Docker 1.8+ or Java 1.8 – desktop, server or cloud and has been tested on Linux, MacOS and Windows. It is licensed as EPL 1.0. diff --git a/docs/_docs/setup/che-setup-managing.md b/docs/_docs/setup/che-setup-managing.md deleted file mode 100644 index 3ce46a8698b..00000000000 --- a/docs/_docs/setup/che-setup-managing.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Managing -excerpt: "" -layout: docs -permalink: /:categories/managing/ ---- -{% include base.html %} -# Scaling -Eclipse Che is a workspace server. It supports the provisioning and management of numerous workspaces for users. The default configuration of Che has a single identity per server, where the identity manages IDE preferences and SSH keys for workspaces and GitHub. - -There are three aspects to scaling Che: -1. Multi-client [collaboration]() within a workspace -2. Scaling Che using a [Che farm]() -3. [Upgrade to Codenvy](http://codenvy.com) - -## Workspace Sizing -The Che server requires 256MB RAM and can handle 1000s of concurrent workspaces. - -For each workspace, assume that the Che RAM overhead is 200MB-1.5GB, but it varies widely by the type of intellisense you add into the workspace. Your users will get the remaining RAM for use by their commands. So if you create a workspace with 2GB of RAM, some of that will be used by Che for its internal management of the workspace itself. - -The RAM variation and amount is relatively high and a function of which plug-ins are deployed into the workspace agent. For example, the Java plug-in which uses JDT core to do intellisense can require up to 1GB of RAM. If a developer is doing intensive compilation or dependency analysis, the workspace will bear the burden of providing the resources needed for these actions. - -Your workspace RAM can go higher if your users are creating multiple machines. Each workspace is given at least one machine. If you permit developers to launch other machines in a single workspace, those machines by default do not have a workspace agent and all of the RAM allocated to that machine will be granted to the user. - -Storage is consumed by: -1. Images downloaded and cached by Che for creating new workspaces. -2. Project files. -3. Workspace snapshots, which create new images saved in a registry. - -Generally, workspace images start at 180MB. If you permit workspace snapshots, those files can grow quite significantly, especially if your developers have large dependency sets such as maven repositories that they want captured in the snapshot. - -## Multi-Client Collaboration -Workspaces are both portable and shared. Multiple browser clients (and humans!) can connect to a single Che server running multiple workspaces, or if you prefer, to a single workspace. Users within a single workspace can make use of the runtime and project files. Che implements a last-write-wins policy when multiple users modify the same file. - -## Scaling Che Using a Che Farm - -![Capture_.PNG]({{ base }}/assets/imgs/Capture_.PNG) -You can deploy Che in a farm with an Nginx router. Each user would be provisioned their own Che instance, either running on its own port in a VM. In this configuration, each user can have their own workspaces and identity profile. Note that since Che exports two IP addresses, one for Che and another for the workspace machine running Docker, your router will need to manage traffic for all possible routes [between browser, Che and machines.]() - -## Scaling Che with Codenvy -Your Eclipse Che workspaces and plug-ins will work within [Codenvy](http://codenvy.com). Codenvy is a multi-tenant, multi-user and elastic cloud installed locally or used as a SaaS: -* Workspace distribution with an embedded Docker Swarm -* Operational solutions for monitoring, scaling, upgrading and archiving workspaces -* Team management, permissions and resource policy management tools -* User authentication, single-sign on, and LDAP -* Self-service user registration -![ScaleCodenvy.PNG]({{ base }}/assets/imgs/ScaleCodenvy.PNG) -Codenvy uses Docker to install, configure, and update various internal services. This creates a simple management interface for administrators with flexibility on how many physical nodes to allocate along with the resource policy management that is applied to users and accounts. - -# Upgrading -Upgrading Che is done by downloading a `eclipse/che-cli:` that is newer than the version you currently have installed. You can run `eclipse/che-cli version` to see the list of available versions that you can upgrade to. - -For example, if you have 5.0.0-M2 installed and want to upgrade to 5.0.0-M8, then: -``` -# Get the new version of Che -docker pull eclipse/che-cli:5.0.0-M8 - -# You now have two eclipse/che-cli images (one for each version) -# Perform an upgrade - use the new image to upgrade old installation -docker run eclipse/che-cli:5.0.0-M8 upgrade -``` - -The upgrade command has numerous checks to prevent you from upgrading Che if the new image and the old version are not compatible. In order for the upgrade procedure to advance, the CLI image must be newer that the version in `/instance/che.ver`. - -The upgrade process: -1. Performs a version compatibility check -2. Downloads new Docker images that are needed to run the new version of Che -3. Stops Che if it is currently running -4. Triggers a maintenance window -5. Backs up your installation -6. Initializes the new version -7. Starts Che - -# Backup -You can run `che backup` to create a copy of the relevant configuration information, user data, projects, and workspaces. We do not save workspace snapshots as part of a routine backup exercise. You can run `che restore` to recover che from a particular backup snapshot. The backup is saved as a TAR file that you can keep in your records. You can then use `che restore` to recover your user data and configuration. - -# Security -Eclipse Che is designed as a single identity system to be used by an individual or small team working in a trusted environment. The following outlines some of the security capabilities and known gaps in Che. - -## Securing Che Ports -Firewall rules can be added to prevent access to ports that shouldn't be externally accessible. Refer to [network topology docs]() for additional information on ports. - -When a remote user (outside the local network) requires access to Che, firewall rules can be setup to allow only certain ip-addresses access. - -## Limiting Che Ports -Eclipse Che uses Docker to power its workspaces. Docker uses the [ephemeral port range](https://en.wikipedia.org/wiki/Ephemeral_port) when exposing ports for services running in the container. So when a Tomcat server is started on port 8080 inside a Che workspace Docker automatically selects an available port from the ephemeral range at runtime to map to that Tomcat instance. - -Docker will select its ports from anywhere in the ephemeral range. If you wish to reduce the size of the ephemeral range in order to improve security you can do so, however, keep in mind that each Che workspace will use at least 2 ports plus whatever ports are required for the services the user adds to their workspace. - -Limiting the ephemeral range can only be done at the host level - you can read more about it (and some of the risks in doing so) here: http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html - -To change the ephemeral range: - * On Linux: http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html#Linux - * On Windows: http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html#Windows - -## Securing a Workspace from the Che Host -It is possible for admins to mount files from your server's host file system to be available to your users within their workspaces with the `CHE_WORKSPACE_VOLUME` and `CHE_DOCKER_PRIVILEGED_MODE` parameters are potential secrity risks as you open the possiblity of sending host-specific files into a workspace or giving a workspace user access to the host system. These options are useful for certain development situations but should be minimized to increase security to the host system whenever possible. - -## Workspace Permissions -Eclipse Che is a single identity system. All users accessing a Che server share an identity and user preferences. There are no identity-based permissions since all users share the same identity. Users have access and control over all workspace environments. - -For a simple separation of workspaces for small development teams, without requiring workspace permissions, administrators can create separate Che server for each user. Each server, if ran on same host, would need to be setup on different ports using the `CHE_PORT` environment variable and different data folders mounted `:/data`. - -Codenvy provides an implementation of Eclipse Che that is multi-tenant, multi-user with distributed access and permissions controls for teams. Each user has a different login which enables access controls, workspace collaboration, and other forms of sharing. You can install Codenvy with a CLI that is nearly identical to Che with `docker run codenvy/cli start. Learn more at [https://codenvy.com](https://codenvy.com). - -## Authenticated Access -The Che server itself is unauthenticated. Che is extensible allowing different dashboard front ends or proxies to implement authenticated access to the Che server. Bitnami's deployment of Eclipse Che includes an authenticated front-end implemented as a proxy. Many users deploy nginx in front of Che to provide an authentication layer within the system. - -Bitnami requires an existing account with cloud providers such as Google, Amazon AWS, or Microsoft Azure which may require monthly service charges from cloud providers. Refer to [Usage: Private Cloud](doc:usage-bitnami) for additional information. - -Codenvy also provides an implementation of Eclipse Che that has multi-user and multi-tenant capabilities. - -## HTTP/S -HTTPS is not provided by Eclipse Che. It would require a more complex architecture with multi-service deployments, making Che more challenging for developers and small teams to use. Codenvy gives you the option of running the system with HTTP/S and providing your own SSL certificate. diff --git a/docs/_docs/tutorials/tutorial-android.md b/docs/_docs/tutorials/tutorial-android.md deleted file mode 100644 index 79c951bd5e4..00000000000 --- a/docs/_docs/tutorials/tutorial-android.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Android in Che -excerpt: "Developing Android apps in Che" -layout: tutorials -permalink: /:categories/android/ ---- -{% include base.html %} -# 1. Select Android Stack and Sample -When in User Dashboard, create a project with Android stack. There are two sample applications to get started with. Both are Maven projects. -# 2. Run Android App (Emulator) -Android stack has everything one needs to package `.apk` (Java, Maven, Android SDK), run Android emulator and install the `.apk` in an emulator. - -When in the IDE, run `build` command that will package the project as `apk`. You will also see a preview URL, which is a VNC URL to get into the environment with x-server running. - -The final instructions are documented in a sample README file: -[block:embed] -{ - "html": false, - "url": "https://github.com/che-samples/mobile-android-hello-world/blob/master/README.md", - "title": "che-samples/mobile-android-hello-world", - "favicon": "https://assets-cdn.github.com/favicon.ico", - "image": "https://avatars1.githubusercontent.com/u/16560000?v=3&s=400", - "iframe": false, - "width": "450px", - "height": "450px" -} - -# 3. Run Android App on Device -It is possible to connect your Android phone or tabled to your machine and use `adb` commands to install `apk` right into a connected device. - -There are a few pre-requisites: - -* in `/conf/che.properties`: -add `machine.server.extra.volume=/dev/bus/usb:/dev/bus/usb` -set `machine.docker.privilege_mode` to `true` - -Vagrant users and those running Che natively on Windows and Mac (i.e. where Virtual Box is involved) need to make sure that the VM can see USB devices connected to the host machine. - -There are two pre-reqs here: - -1. Install VirtualBox Extension Pack. [Instructions](http://www.htpcbeginner.com/install-virtualbox-extension-pack-on-linux-windows/) | [Download Link](http://download.virtualbox.org/virtualbox/5.0.16/Oracle_VM_VirtualBox_Extension_Pack-5.0.16.vbox-extpack) - -2. Enable USB in VM settings. -Vagrant users may either add the following to a Vagrantfile - https://github.com/codenvy/artik-ide/blob/master/Vagrantfile#L16-20 (then destroy the current box and create a new one) - or manually enable USB at Settings > USB (create an empty filter). - -When a workspace starts, you may check if adb can see your phone: - -`adb devices` - -If the phone is there, you may install `apk` right into it: - -`adb install -r /path/to/your.apk` diff --git a/docs/_docs/tutorials/tutorial-che-and-appfog.md b/docs/_docs/tutorials/tutorial-che-and-appfog.md deleted file mode 100644 index 451bfad4a61..00000000000 --- a/docs/_docs/tutorials/tutorial-che-and-appfog.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: AppFog and Che -excerpt: "" -layout: tutorials -permalink: /:categories/che-and-appfog/ ---- -{% include base.html %} -CenturyLink has written a [blog on integrating Eclipse Che and AppFog](https://www.ctl.io/developers/blog/post/cloud-ide-docker-che-eclipse?utm_source=CTLDevCenter&utm_medium=twitter). diff --git a/docs/_docs/tutorials/tutorial-che-in-che.md b/docs/_docs/tutorials/tutorial-che-in-che.md deleted file mode 100644 index c5dbdbc5f8a..00000000000 --- a/docs/_docs/tutorials/tutorial-che-in-che.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Che in Che -excerpt: "There is nothing like a little Che inception to brighten your day." -layout: tutorials -permalink: /:categories/che-in-che/ ---- -{% include base.html %} -You can build and run Che using Che! Since Che runs within a Docker container and its workspaces are generated as Docker containers, there is extra configuration that is needed to enable the Che that you build in Che to generate its own workspaces! -# Concepts -We are going to setup Che to have the Che launcher, the Che server, your primary development workspace, and the new Che you will compile be Docker containers. All of these Docker containers will be launched and managed by a shared Docker daemon, which is running on your host system. -![Capture.PNG]({{ base }}/assets/imgs/Capture.PNG) -* **Native**: The CLI that launches your main instance of Che with the `che-launcher`. -* **Che Launcher**: A Docker container, which provides cross-platform management of your Che server. -* **Che Server**: A Docker container running your primary Che server. -* **Che Workspace**: A Docker container which containers your development workspace. The Che source code is cloned into this workspace, compiled here, and acts as the launch point. It includes the CLI that launches the launcher (creating a type of recursive behavior). The new inner Che will be able to launch its own workspaces. - -All of these containers share a common Docker daemon that is running on the host operating system. This means that even though we are doing Che-in-Che (or why not Che-in-Che-in-Che), all of the containers created are siblings of one another managed by the same daemon. -# Step By Step Guide -### Configure Che -There are two values that you must set as environment variables. This requires the 4.7 CLI - previous versions of the CLI do not support converting environment variables into Che properties. -```text -# This will create a che.properties value -export CHE_PROPERTY_machine_server_extra_volume=/var/run/docker.sock:/var/run/docker.sock - -# Set CHE_DATA_FOLDER to a directory that you will remember. -# This value will be needed inside of the workspace -export CHE_DATA_FOLDER=/Users/tyler/data\ -``` -### Start Che -```shell -# Start Che -che start\ -``` -Now, all workspaces started in this Che server will have access to the host's Docker daemon. Because workspaces will share access to the host daemon, be careful with sharing workspaces in this configuration. It's possible that workspaces can send commands to the daemon that gain privileges to the host that you may not want to give. - -### Get a Che Workspace -1: Create a workspace using the Eclipse Che ready-to-go stack. It will have the Che logo next to it. This stack is based upon Alpine and [includes Java 8, maven, and the Docker client](https://github.com/eclipse/che-dockerfiles/tree/master/recipes/alpine_jdk8). - -2: Choose the Eclipse Che template. This will clone source from `http://github.com/eclipse/che` and give the resulting project a `maven` project type. Setting the type to maven will trigger dependencies being downloaded. It's a big project - so it will take a moment to finish the clone and create the workspace. - -4: Project > Set Configuration. Set the project configuration to be `maven`. This will add Java intellisense and the maven plugin so that your dependencies are managed properly. - -5: Compile Che by adding a maven command. In the toolbar, choose "Edit Commands...". Create a new maven command. Set the working directory to be /che/assembly/assembly-main. The command should be `clean install`. - -### Run Che-in-Che -Now that you have a compiled Che binary, you need to run it. We will use the Che Launcher Docker container to run the binary. Your workspace project has all of its files mounted onto the host. So while you see the files inside your workspace, they are also running on the host - where the Docker daemon is. - -We will launch the Che Launcher from inside the workspace, but pass environment variables that allow the launcher to create a new Che server on the host, and that new Che server will be started with the binaries that you just compiled (also on the host). -```shell -# First, find the location where Che built itself in your workspace. -cd /projects - -# Replace and with your setup -set MY_CHE_BINARY="//assembly/assembly-main/target//" - -# Your che-in-che will launch itself with the name "che-server" -# Temporary fix - to avoid collisions, rename your dev server container. -docker rename che-server che-primary-server - -# Create a new data directory. -mkdir /home/user/che-did - -# Inside your Che workspace, launch Che-in-Che with: -sudo docker run --rm -t -v /var/run/docker.sock:/var/run/docker.sock - --env CHE_LOCAL_BINARY=/home/user/che/workspaces/$MY_CHE_BINARY - --env CHE_DATA_FOLDER=/home/user/che-did - --env CHE_HOST_IP=$(curl -s https://4.ifcfg.me/) - --env CHE_PORT=50000 - eclipse/che start - -# NOTE: Set the CHE_PORT to any value >33,000 -# NOTE: Set the CHE_PORT to a value not used by your primary Che server or workspace -# NOTE: CHE_HOST_IP only necessary if you are running Che as a shared server - -# CHE-IN-CHE will be running at http://$CHE_HOST_IP:50000 -``` diff --git a/docs/_docs/tutorials/tutorial-cuba.md b/docs/_docs/tutorials/tutorial-cuba.md deleted file mode 100644 index 89b63e3590b..00000000000 --- a/docs/_docs/tutorials/tutorial-cuba.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Cuba Platform in Che -excerpt: "" -layout: tutorials -permalink: /:categories/cuba/ ---- -{% include base.html %} -CUBA Platform is a high level Java framework for faster enterprise software development. -```text -#When on the User Dashboard, create a new project from existing sources: -https://github.com/Haulmont/platform-sample-sales - -#Choose a Custom Stack and add the following recipe: -FROM codenvy/cuba\ -``` - -```text -#When the IDE opens, create a custom command: -Title: start-platform -Command: /home/user/studio-2.0.6/bin/studio -nogui -Preview: http://${server.port.3080}\ -``` - -```text -#Click the preview URL. When in CUBA Platform, import an existing project from `/projects/platform-sample-sales` - -#Build and run it. When a Tomcat starts, navigate to Machine perspective > Servers tabs. Find the port that corresponds to 8080.\ -``` diff --git a/docs/_docs/tutorials/tutorial-ftpsftp.md b/docs/_docs/tutorials/tutorial-ftpsftp.md deleted file mode 100644 index da157b71775..00000000000 --- a/docs/_docs/tutorials/tutorial-ftpsftp.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: FTP/SFTP and Che -excerpt: "" -layout: tutorials -permalink: /:categories/ftpsftp/ ---- -{% include base.html %} -##Add FTP / SFTP into a workspace -Che has Midnight Commander installed in the Terminal, so it's possible to use it to connect to a remote FTP server. - -Just open your workspace in the IDE, go to the Terminal, execute `mc` and press F9 to call the menu. Select `Left`/`Right` window, select `FTP Link`. - -Enter FTP server details in one of the following formats: -```shell -username:password@host #for non-anonymous login; -host #for anonymous login; -!username:password@host #for servers behind the firewall, through proxy servers; -username:password@host:port #for servers using non std port; -username:password@host/directory #to go to specific directory.\ -``` -##Synchronize projects -Once you've connected to your remote FTP server, you can copy any files or projects between the `/projects` directory in your Che workspace and any directory on your remote FTP server. diff --git a/docs/_docs/tutorials/tutorial-gae.md b/docs/_docs/tutorials/tutorial-gae.md deleted file mode 100644 index 7b1fa830ae8..00000000000 --- a/docs/_docs/tutorials/tutorial-gae.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Google App Engine and Che -excerpt: "" -layout: tutorials -permalink: /:categories/gae/ ---- -{% include base.html %} -```text -# When on the Dashboard create a new project with PHP GAE or Python GAE stack from the Stack Library and a sample PHP or Python project. \ -``` - -```text -# Run command for PHP GAE project will have the following syntax: - -Command: cd ${GAE} && ./dev_appserver.py 2>&1 --php_executable_path=/usr/bin/php5-cgi --skip_sdk_update_check true --host=0.0.0.0 --admin_host=0.0.0.0 ${current.project.path} -Preview URL: http://${server.port.8080} - -# For Python GAE project: - -Command: cd ${GAE} && ./dev_appserver.py 2>&1 --skip_sdk_update_check true --host=0.0.0.0 --admin_host=0.0.0.0 ${current.project.path} -Preview URL: http://${server.port.8080}\ -``` - -```text -# Choose `run` command from the CMD widget to test your application. Make some changes to the project and execute `run` command again to see changes. \ -``` - -```text -# Go to the Terminal, cd /home/user/google_appengine/ directory and run `./appcfg.py --noauth_local_webserver update /projects/{YOUR_PROJECT_NAME}/` command to deploy it. Copy link, enter a verification code and check your changed app at GAE.\ -``` diff --git a/docs/_docs/tutorials/tutorial-gradle.md b/docs/_docs/tutorials/tutorial-gradle.md deleted file mode 100644 index c2d120c0408..00000000000 --- a/docs/_docs/tutorials/tutorial-gradle.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Java+Gradle in Che -excerpt: "" -layout: tutorials -permalink: /:categories/gradle/ ---- -{% include base.html %} -Gradle is an open source build automation system that builds upon the concepts of Apache Ant and Apache Maven and introduces a Groovy-based domain-specific language (DSL) instead of the XML form used by Apache Maven of declaring the project configuration. -```text -#Import a project from source: -https://github.com/che-samples/console-java-gradle - -#Select Custom stack > Write your own stack option. The recipe goes as follows -FROM eclipse/ubuntu_gradle\ -``` - -```text -#In the IDE create a custom command with the following syntax to build your project: -Title: build -Command: cd ${current.project.path} && gradle build -Preview: - -#Create a new custom command to run your application. In this case the command syntax will be: -Title: run -Command: java -jar ${current.project.path}/build/libs/*.jar -Preview: - -#Run commands may vary depending on the application type (console, webapp etc.)\ -``` - -```text -# Test your application -1. Execute `build` command. -2. After a successful project build run the `run` command. -3. See the output on the Consoles panel.\ -``` diff --git a/docs/_docs/tutorials/tutorial-java.md b/docs/_docs/tutorials/tutorial-java.md deleted file mode 100644 index 3386fe96da6..00000000000 --- a/docs/_docs/tutorials/tutorial-java.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Java Console Apps in Che -excerpt: "" -layout: tutorials -permalink: /:categories/java/ ---- -{% include base.html %} -# 1. Start any Java stack -Go to Workspaces tab in User Dashboard, pick any Java stack, create a workspace and run it. -# 2. Create a Java project -When in the IDE, go to Workspace > Create Project > Java. A wizard will ask for a project name and sources directory location. -# 3. Compile and run -When a project shows up in project explorer, open `src/Main.java`. Hit Ctrl+Space ti check code auto-completion, see error marking in action etc. - -To compile and run the project, go to `Edit Commands`, choose Java type command, press `+` button to add a new command. - -By default, `Main.java` is a main class and the command syntax uses this name. However, it is possible to choose another main class and the command will adjust itself accordingly. -# 4. Add a library to classpath -If your project uses 3rd party libraries, they should be added to classpath at `Project > Configure Classpath`. Before adding a jar to project classpath, it should be uploaded to the project at `Project > Upload File`. diff --git a/docs/_docs/tutorials/tutorial-laravel.md b/docs/_docs/tutorials/tutorial-laravel.md deleted file mode 100644 index d97011c0617..00000000000 --- a/docs/_docs/tutorials/tutorial-laravel.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Laravel in Che -excerpt: "" -layout: tutorials -permalink: /:categories/laravel/ ---- -{% include base.html %} -Laravel is a free, open-source PHP web framework, created by Taylor Otwell and intended for the development of web applications following the model-view-controller (MVC) architectural pattern. -```text -# In the dashboard, create a new workspace from the custom stack using the following image: -FROM eclipse/php:laravel\ -``` - -```text -#In the Terminal execute `laravel new {your-project-name}` command to create a new project.\ -``` - -```text -# In the IDE, create a new command. Give it the syntax: -Title: run -Command: cd ${current.project.path} && php artisan serve --host=0.0.0.0 --port=3306 -Preview: http://${server.port.3306}\ -``` - -```text -# Test your application -1. Run the `run` command. -2. Open any file. -3. Make some edits. -4. Refresh the web app in the preview URL to see your changes.\ -``` diff --git a/docs/_docs/tutorials/tutorial-maven.md b/docs/_docs/tutorials/tutorial-maven.md deleted file mode 100644 index 5ba3e244cb1..00000000000 --- a/docs/_docs/tutorials/tutorial-maven.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Java+Maven in Che -excerpt: "Che was written in Java. Experience the rich Intellisense and Java tools in this tutorial." -layout: tutorials -permalink: /:categories/maven/ ---- -{% include base.html %} -# 1. Start Che -Use your SaaS account for the following, or if you have [installed Che](https://eclipse-che.readme.io/v5.0/docs/che-getting-started), open a terminal and use the Che startup script: -```shell -# Launch Che -che start\ -``` -When you execute this command, you'll see the URL for the user dashboard. - -The Che dashboard will open. It is where you manage your projects and workspaces. If you do not have any projects in Che, you'll be asked to create a new project. If you already have projects in Che, click on `New Project` button in the menu bar. -# 2. Create Console Java Project -From the Dashboard page click "Create Workspace". - -### Select Source -![ScreenShot2016-09-30at5.56.22PM.png]({{ base }}/assets/imgs/ScreenShot2016-09-30at5.56.22PM.png) -This informs Che where the source code for your project is going to come from. It is possible to start a new blank, template, sample project or import one from another location. Choosing the first option will present you with a set of samples that are preconfigured. If you already have a project at a valid URL, choose the second option. Che gives you choices on how to source the project from Git, GitHub, ZIP, etc.. - -We will create a project from a provided template. - -###Select Stack -![ScreenShot2016-09-30at5.52.21PM.png]({{ base }}/assets/imgs/ScreenShot2016-09-30at5.52.21PM.png) -Your project will be inserted into a workspace, which has a provided Docker runtime. Stacks are the recipes or images used to define the runtime environment for the workspace where your project will be placed. There are three ways to choose a stack: -1. *Ready-To-Go Stacks.* Environments that have a large variety of tools already installed optimized for projects of a particular type. For this example, we will select the Java stack which will create a container with Ubuntu git, java-jdk, maven, tomcat installed. -2. *Stack Library.* Offers finer grained stacks that can be used to create specific technology layers needed for a project. Ubuntu and Debian stacks, for example, are minimal stacks with only an operating system and Che tools installed. -3. *Custom Stack.* You can provide your own custom stack. You'll have the ability to upload a recipe (dockerfile) or directly edit it from there. - -Choose the `Ready-To-Go` category and select the `JAVA` stack. - -### Configure Workspace -![ScreenShot2016-09-30at5.55.07PM.png]({{ base }}/assets/imgs/ScreenShot2016-09-30at5.55.07PM.png) -Provide a name to your workspace and configure its RAM. RAM will be the memory limit applied to the machines running your workspace environment. For this tutorial, create a new workspace with name `tutorial-java` and set its RAM to 1GB. - -###Select Template (Code Sample) -![ScreenShot2016-09-30at5.55.58PM.png]({{ base }}/assets/imgs/ScreenShot2016-09-30at5.55.58PM.png) -A template is a set of code, configuration, and commands that can be imported to operate within Che. There are two types of templates: -1. **Ready-to-run project samples**. These samples have a compilable source tree and embedded commands. The list of templates available are filtered based upon the stack chosen. -2. **Wizard-driven project configuration**. This creates a blank project and then opens the IDE's project configuration wizard to let you scaffold a new project based upon a set of configurable parameters. This option is only available if there an appropriate project type available for the stack chosen. - -Choose `Ready-to-run project samples` and select `console-java-simple`, those options should be preselected by default. - -### Project Metadata -![ScreenShot2016-09-30at5.56.22PM.png]({{ base }}/assets/imgs/ScreenShot2016-09-30at5.56.22PM.png) -You can set a name and description of your project. The name is what will appear as the root node in the project explorer in the IDE. Keep the default values. - -### Create the Project - -Hit the button **Create** at the bottom of the flow. The project construction will start. - -The project construction process goes through a number of steps including creating a new workspace, downloading an image to use for the workspace environment, instantiating that environment, installing Che services into the workspace, and then creating your project. -# 3. Develop in the IDE -The project created is a Maven project. Once you open it in the IDE, you'll see the dependencies updated from the `pom.xml` file. -![ide-update-dep.png]({{ base }}/assets/imgs/ide-update-dep.png) -### Project Explorer -![project-tree.png]({{ base }}/assets/imgs/project-tree.png) -On the left side of the IDE, a panel is displaying the project explorer which allow you to browse the sources of your project. You can use your mouse to expand/collapse the folders and packages, but you are also able to navigate in the project explorer using your keyboard. Use: -- `up arrow` and `down arrow` to navigate in the tree, -- `left arrow` and `right arrow` to expand/collapse folders and packages, -- `enter` to open a file. - -### Editor Overview -Open the file `HelloWorld.java` in the package `org.eclipse.che.examples`. The file is displayed with syntax coloration. -![editor-simple.png]({{ base }}/assets/imgs/editor-simple.png) -The editor is structured in a common way: -- at the top: the list of all opened files, -- on the left: line number, breakpoints and error marks, -- on the right: the file's minimap and the cursor position bar to navigate in the file, -- at the bottom: file information (cursor exact position, encoding and file's type). - -If you have error in your files, the editor will display error and warning marks: -![editor-errors.png]({{ base }}/assets/imgs/editor-errors.png) -You can use your keyboard to navigate in the file content, but also between files. You can get the complete list of all keyboard shortcut by going into the menu `Assistant` > `Key Bindings` and scrolling to the category `Editor` -![keybindings.png]({{ base }}/assets/imgs/keybindings.png) -### Java Intellisense -There is an Assistant menu that includes language specific capabilities. You can perform auto-complete by hitting `ctrl-space`. - -### Jump to Definition -While you are editing your Java code, you may want a documentation lookup for a particular symbol (class, attribute or method). Get quick documentation by `Assistant` > `Quick Documentation` or `^j`. -![quick-documentation.png]({{ base }}/assets/imgs/quick-documentation.png) -If you need more information about the symbol, you can also navigate to its definition with `Assistant` > `Open Declaration` or `F4`. The `String` class will open in a new editor. -![open-declaration.png]({{ base }}/assets/imgs/open-declaration.png) -### Search -Che editor provides various ways to search your projects and workspace. - -#### Search with Editor -Use the editor search to find and replace in a particular file via `CTRL+f` keyboard shortcut. You can also use regular expressions. -![find-editor.png]({{ base }}/assets/imgs/find-editor.png) - -#### Find Usages -This will find all references of a particular class, method, field or attribute and search for its usage in your various project's files. Do this with `Assistant` > `Find Usages`. A new panel will open and list all references for `String` into your project. If you select one of the occurrence and double-click on it, the editor will open the file to the position of the found reference. - -![find-usages.png]({{ base }}/assets/imgs/find-usages.png) - -### Refactoring -Che provides the ability to refactor your source code. - -#### Rename -Put cursor on method, variable or field that you want to rename, and hit Shift + F6. If this hotkey is pressed once, the selected keyword will be highlighted which means it's ready for refactoring. You can type a new name and press Enter. - -If you press Shift + F6 twice, an advanced Rename mode is called out: -![rename.png]({{ base }}/assets/imgs/rename.png) -Preview button will open a side by side comparison window that will show changes that you are about to apply. - -#### Move -Choose any Java class you want to move and hit F6. It will call a Move item menu. Choose destination for your class and click OK. - -![move-item.png]({{ base }}/assets/imgs/move-item.png) -It's also possible to preview changes. Choose destination for your class and click Preview. It will show all Java classes and non-Java files (optional), that the replaced class is referenced in. -![preview.png]({{ base }}/assets/imgs/preview.png) -###Manage Maven Modules -Maven Plugin provides the ability to manage Maven modules in multi-module projects entirely through `pom.xml`. - -Open any Java multi-module project and create a new folder with a simple Maven project in it. It will be seen as folder in the project tree first. Open your parent project POM and add your newly imported module there: -`new-module` - - As a result, it will be automatically configured as a Maven module in your project tree. Maven plugin watches changes in `pom.xml` and automatically imports changes (dependencies, configuration etc). - -###Dependency Management -If you make changes to dependencies in POM, they will be automatically updated. You can also manually reimport the project: right click on your Maven project, choose `Maven > Reimport`. - -If you have errors in your POM or add some nonexistent dependency to your POM, the following error will be displayed in the editor: -![nonexistent-dependency.png]({{ base }}/assets/imgs/nonexistent-dependency.png) -###Configure Classpath -It's possible to view project dependencies at `Project > Configure Classpath`. Dependencies in the classpath will be categorized as follows: -- JRE_CONTAINER - Java 1.8 jars; -- MAVEN2_CLASSPATH_CONFIGURATION - project dependencies. -![configure-classpath.png]({{ base }}/assets/imgs/configure-classpath.png) -###Generate Effective POM -There is also a possibility to display POM that results from the application of interpolation, inheritance and active profiles. Just open your Maven project and go to `Assistant > Generate Effective Pom`. diff --git a/docs/_docs/tutorials/tutorial-meteor.md b/docs/_docs/tutorials/tutorial-meteor.md deleted file mode 100644 index 041767d026f..00000000000 --- a/docs/_docs/tutorials/tutorial-meteor.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Meteor in Che -excerpt: "" -layout: tutorials -permalink: /:categories/meteor/ ---- -{% include base.html %} -# 1. Start Che -Run `docker run --rm -t -v /var/run/docker.sock:/var/run/docker.sock eclipse/che start` and open your browser at `http://:8080` - -# 2. Start Workspace -When in User Dashboard, go to `Workspaces` tab and click `(+)` button. It will take you to a Wizard with all the steps to create a new workspace. - -### Select Source -We’ll create a new workspace using recipe, so choose an appropriate option in the menu. - -###Select Stack -Our workspace will be created from a **Custom Stack** (tab on the far right). We’ll use a certified Debian based Codenvy image with NodeJS 5.6.0 and Meteor installed ([Recipe](https://raw.githubusercontent.com/eclispe/che-dockerfiles/master/meteor/latest/Dockerfile)). - -Our custom recipe will be: - -`FROM eclipse/meteor` - -(There's also `eclipse/meteor:ubuntu` tag for those who love Ubuntu). There's only one instruction since all the commands are executed in the base image. - -Finally, give your workspace a nice name, configure RAM and you are all good to go. - -# 3. Create Meteor Project -Once you workspace is created, open it in the IDE with `(>)` button (it will take a while for Docker to pull the base image). When in the IDE, go to the Consoles panel on the bottom of the IDE, click (+) button to open a new terminal tab and run meteor --version to check if it’s successfully installed. - -Go to the projects directory and run meteor create {your-app-name} command to create a new Meteor app: - -`cd /projects && meteor create simple-todo` - -Click Refresh project tree button on the Project Explorer panel and find your soon-to-be project. Click `(>)` button to configure it. Choose Blank project type and save changes. - -# 4. Run Meteor Project -In the Commands Widget, go to `CMD > Edit commands…` and click `(+)` button to create a custom command. Name the command, a definite it: - -`cd ${current.project.path} && meteor` - -Here, we use a special IDE macro that will be interpreted as an absolute path to a currently selected project. - -Preview URL is very important. When a process starts on a particular port in the container, we can only access it from outside the container, on a mapped port that Docker has randomly chosen when launching the container. Here we will use a few more macros to build a preview URL: - -`http://${server.port.3000}` - -`${server.port.3000}` will return `currentHost:mappedPort`. See: IDE Macros. - -If you switch to a Machine perspective, Servers tab, you will find all available port mappings, including the meteor one. - -Save your custom command, run it and click the preview URL. Congrats! Your first Meteor app is running. -# Q&A -## What if I need a different Node version? - -`eclipse/node` image is built on top of eclipse/debian_jre that has all the things required to run a Che workspace. Node installation was performed according to instructions in the official `node` Dockerfiles on DockerHub. - -If you need a different node version, we recommend taking a look at the original [Dockerfile](https://github.com/eclipse/che-dockerfiles/blob/master/meteor/debian/Dockerfile) and grab instructions from official [Node Dockerfiles](https://github.com/nodejs/docker-node/tree/0c722500f66fb5f606a57824babe9798ae98667b). - -## Can I install anything through npm? - -Yes, if you need things like bower, gulp, ionic and what not, just add an extra RUN instruction to your custom recipe: -```shell -FROM eclipse/meteor -RUN sudo npm install -g gulp bower grunt ionic\ -``` -## Can I override the default CMD? diff --git a/docs/_docs/tutorials/tutorial-multi-machine.md b/docs/_docs/tutorials/tutorial-multi-machine.md deleted file mode 100644 index c69561a7834..00000000000 --- a/docs/_docs/tutorials/tutorial-multi-machine.md +++ /dev/null @@ -1,144 +0,0 @@ ---- -tags: [ "eclipse" , "che" ] -title: Multi-Machine Workspaces in Che -excerpt: "" -layout: tutorials -permalink: /:categories/multi-machine/ ---- -{% include base.html %} -A multi-machine recipe allows multiple runtimes to communicate/share data. In this tutorial we will be looking at an existing Java and MySQL application called Pet Clinic. The tutorial will help show how to create a multi-machine from an existing [runtime stack](doc:stacks) called "Java-MySQL", execute commands on different target runtimes, startup the Pet Clinic Tomcat server, view/interact with the Pet Clinic web page, and take a closer look at the "Java-MySQL" [runtime stack](doc:stacks) /[runtime recipe](doc:recipes) to get a better understanding of how multi-machine runtimes are created. - -# 1. Start Che -Use your SaaS account for the following, or if you have [installed Che](https://eclipse-che.readme.io/docs/che-getting-started), open a terminal and use the Che startup script: -```shell -# Launch Che -che start\ -``` -When you execute this command, you'll see the URL for the Che server. - -This URL can be used to open Che server's dashboard. It is where you manage your projects and workspaces. -# 2. Create Workspace -Click the "Dasboard" menu item in the dashboard. Click the "New Workspace" button if there are existing workspaces or make sure "Select Source" category is set to "New from blank, template, or sample project" if one or more workspace exists. -![che-multimachine-tutorial3.jpg]({{ base }}/assets/imgs/che-multimachine-tutorial3.jpg) -Select "Java-MySQL" from the list of available stacks. -![che-multimachine-tutorial1.jpg]({{ base }}/assets/imgs/che-multimachine-tutorial1.jpg) -The other workspace information can remain as it is. Click the "create" button at the bottom to create the workspace. -![che-multimachine-tutorial2.jpg]({{ base }}/assets/imgs/che-multimachine-tutorial2.jpg) - -# 3. Using IDE -Once the workspace is created, the IDE will be loaded in the browser. - -Each runtime can be identified in the processes section of the IDE. It will list the runtimes of "dev-machine" and "db" of our multi-machine workspace. The "db" runtime for this tutorial provides the database for the Java Spring application to use. - -To make sure that the database is running we will issue the "show database" command to the "db" runtime. Select the "db" runtime item from the target drop down menu. Then make sure that "show databases" is selected in the command drop down menu and hit the play button. -![che-multimachine-tutorial4.jpg]({{ base }}/assets/imgs/che-multimachine-tutorial4.jpg) -This will run the "show databases" command in the "db" runtime and display the available database. Note that it is not required to know the database listed for this tutorial. This step merely shows how to successfully target different runtimes. - -Switch the target back to "dev-machine", select the "web-java-petclinic: build and deploy" command, and click the play button. The Pet Clinic Java code will be compiled and the tomcat server started. Give the server ample amount of time to start as the server output may stay on `INFO Version - HCANN000001: Hibernate Commons Annotations {4.0.5.Final}` for awhile. The tomcat server when it is ready will output `Server startup in